kyon_mm 2013.07.28 TDDeXchange

TDDの自殺TDDとドメインと仕様と

Self Introduction

きょん(@kyon_mm)

テストエンジニア

Groovy, C#, F#, Scala

SCMBootCamp, Nagoya.Testing, CDStudy, 基礎勉強会, Cafe.Testing, STAR

Agenda

TDDの概要

ドメイン

理想のコード

TDDとドメイン

まとめ

TDD概要

Definition of TDD

TDDとはソフトウェア開発者向けフレームワークである。

RED, GREEN, REFACTORというアクティビティのスパイラルモデルが根幹にある。

What kind of FW

TDDは次の2点を支援するフレームワーク

「開発者の意図を確認すること」

「開発者が心地よいコードを書き始める事」

TDD Foundation

客観的で頻繁にも実施できる検査群

確認し易い検査結果群

RED,GREEN,REFACTORのライフサイクル

Agenda

TDDの概要

ドメイン

理想のコード

TDDとドメイン

まとめ

ドメイン

Domain

ドメインの分け方として２分別する方法がある

アプリケーションドメイン

ソリューションドメイン

Application Domain

ソフトウェアシステムの導入によって変化させたい領域のこと。

問題ドメインと呼ばれる事が多いが、必ずしも一致しない。

Application Domain

端的な例だと、要求レベルで表現できるユーザーが達成しようとしている内容

Solution Domain

ソフトウェアシステムの個々の技術や組み合わせ方。

解決ドメイン、解決領域と翻訳されることもある。

Solution Domain

個々の言語、ライブラリ、ミドルウェアなど。

実際のコードや設定やインフラなどによる実装技術。

Agenda

TDDの概要

ドメイン

理想のコード

TDDとドメイン

まとめ

理想のコード

Best Production Code

Application DomainとSolution Domainが同一表現になること。

「やりたいことを書いた」=「実装した」

Example

MDA系

一部では概念図からプロダクトコードを自動生成することに注力している

DSL系

アプリケーションドメインをそのままかけるような専用言語によってソリューションドメイン

Example

BRMS

システムのロジックの一部をデシジョンテーブルで記述できるようにする

Domain Specific Language小休止

Real Production Code

アプリケーションドメインの記述のみで全てのソリューションドメインを記述する事はできていない。

DDDはこの2ドメイン間を橋渡しするための方法論

Domain Specific Language

DSLを2分別する方法がある

External DSL

Internal DSL

ExternalDSL /Internal DSL

ExternalDSL(外部DSL)

一つの言語として確立されているもの

SQL/XML/Regular Expression/Puppet

Internal DSL

InternalDSL(内部DSL/Embedded DSL)

ある言語の拡張として作られた言語

フレームワーク/Gradle/Chef

Agenda

TDDの概要

ドメイン

理想のコード

TDDとドメイン

まとめ

TDDとドメイン

Problem

我々の世界はそこまで綺麗にコードをかける実力もツールもない

TDD Solution

まずテストコードに達成したい事を表現する

プロダクトコードを実装する

テストが通った状態で綺麗にする

Test Code of TDD

TDDはDog Foodingである

テストコードが最初のユーザー

テストコードに要求を書いている

テストコードにアプリケーションドメインがある

Production Code of TDD

まずはある範囲で保証できるコードを書く

保証できる中で綺麗にしていく

TDDの中でどうやってテストとプロダクトを綺麗にするかは語られていない。

TDD用のリファクタリングがない

Best Production Code

アプリケーションドメイン= ソリューションドメイン

TDD

テストコード = アプリケーションドメイン

プロダクトコード = ソリューションドメイン

Product Refactoring

実際にはなんらかの形でアプリケーションドメインをプロダクトコードに入れている

命名、依存関係整理、レイヤ分割

Test Refactoring

DRY...?

Domain

テストコードにアプリケーションドメインが残ってしまっている。

アプリケーションドメインが重複している。

Domain

重複しているだけならまだいい。

実際には違うものが表現されている。

Example

TestDouble

Integration Test

Domain

TestDoubleもしくはIntegrationTestのsetupを書く事で、既にある他の機能の劣化コピーもしくは完全なコピーを書く事になる。

Domain

ツールとTDDの都合でテストコードもしくはプロダクトコードにあるアプリケーションドメインを変化させてコピーしなければいけない

Domain

そのテストを動かすために最短でセットアップできるものを書くのは本当に正しいのかも怪しい。

何よりアプリケーションドメインが重複している。

TDD Suicide

プロダクトコードからアプリケーションドメインが漏れたり、埋め込まれないことがある

それを促進する力がTDDにはある

TDD Suicide

アプリケーションドメインがないプロダクトコードなんて何やっているかわからない死体と同然である。

TDDは開発の理想を壊す、守るべきプロダクトコードを死体にしてしまう事がある。だが、それに気づきにくい。

TDD Suicide

レゾンデートルを自ら破壊してしまうというTDDはまさに自殺しているに等しい。

「ドメインの重複、エセドメインの生産をしてプロダクトコードをダメにしてしまう」というTDDは自殺している。これをTDDの自殺という。