« [記事紹介] Visual Studio のインテリセンスって、テストファースト中には邪魔だよね | トップページ | [ブログ紹介] Writing Unit Tests in F# »

2011年11月 3日 (木)

[コラム] TDD は止めて、 DbE (例示による設計) と呼ぼう!

2年前に、 "It’s Not TDD, It’s Design By Example" (TDD じゃない、例示による設計だ!) というブログ記事が書かれています。
いちおう URL を挙げておきますが、 英文です。

Brad Wilson: It’s Not TDD, It’s Design By Example
April 18, 2009

記事の趣旨は、 TDD という名前が TDD の目的を表していない (だから、 改名しようよ) ということです。
「テスト駆動」という言葉からは、 その目的がテストによる品質保証であると誤解されかねません。 しかし TDD は、 メソッドの外部設計を自動化されたユニットテストという形で例示し (具体例で外部設計を説明する、と言っても良い)、 それを満たす実装を作り、 そしてリファクタリングによって内部設計を改善します (読みやすく理解しやすいコードにします)。 TDD の目的はユニットテストのレベルでプログラムの一部分を設計することにあり、 それは外部設計の例示から始まるので、 "Design By Example" (例示による設計) なんだ、 というわけです。

残念ながら DbE という呼び方は、 2年以上経った現在も普及していません。 ですが、 TDD は品質保証を第一義としたものではないと、 繰り返し言う必要はありそうです。

※ 品質保証では、 品質を表す何らかの指標を計測しなければなりませんが、 そもそも TDD では何も計測していません。  TDD 終了時には、 ユニット「テスト」の結果は ALL GREEN、 すなわち「バグ0」ですし。 TDD 終了後に、 コードカバレッジを取って TDD 三原則を守って TDD したかどうか (守っていれば C0 100% になる)、 コード分析ツールを使って適度にリファクタリングしたかどうか (リファクタリングをさぼっていると、 保守性の点数が下がる)、 サイクロマティック複雑度とテストケース数を比較して余分なテストケースを書きすぎていないか (テストファーストに必要なテストケースの最小数は、 複雑度+α)、 といった情報は取れますが、 TDD のプラクティス外の話です。

さて、 この改名運動があったことを知ると、 理解できることがあります。
このブログの著者 Brad Wilson 氏は、 「Microsoft .NET でのテスト駆動開発」  などの著者として知られる James Newkirk 氏らと共に、 xUnit.net の開発をしています。 テストケースを表すメソッドに、 NUnit では [Test] 属性を付けるところを、 xUnit.net では [Fact] (事実 = なされること・行為) 属性に変えていますが、 それは DbE の考えに基づくものだったのです。 (上記の記事では、 その顛末についても触れられています。)

|

« [記事紹介] Visual Studio のインテリセンスって、テストファースト中には邪魔だよね | トップページ | [ブログ紹介] Writing Unit Tests in F# »

*コラム」カテゴリの記事

コメント

コメントを書く



(ウェブ上には掲載しません)


コメントは記事投稿者が公開するまで表示されません。



トラックバック


この記事へのトラックバック一覧です: [コラム] TDD は止めて、 DbE (例示による設計) と呼ぼう!:

« [記事紹介] Visual Studio のインテリセンスって、テストファースト中には邪魔だよね | トップページ | [ブログ紹介] Writing Unit Tests in F# »