テスト駆動開発のテストは、テストか？－TDD から BDD へ – An Agile Way [ITmedia オルタナティブ・ブログ]
最近TDDのテストコードは契約による設計での契約書なんだよなぁと考えていたりする。
あと、GUIのデザインを本格的に始まる前に、機能試験仕様書を書いてしまう、特に例外処理の試験を書いてしまうのも有効かなと思ったり。後付で醜くしてしまうより、システムとしてユーザーに対してリカバリー出来る（してもらえる）部分が大きい気がする。
TDDのテストはテストなのか?
オブジェクト指向・システム開発
コメント
大規模プロジェクトに全面的に適用したことはありませんが、あきらかにすらすら読めるのは”あなただから”ってのが多すぎるように思います。
実際のユーザさんとの温度差が激しすぎるのは私だけでしょうか。
TDDのテストコードに関しては、開発者が読む物なで、その中で読める物なら良いでしょう。（そもそも開発者が読めないテストコードを書く人間の書くコードって言うのは。。）
また、ユーザーインターフェイス、特に例外処理に関するユーザーインターフェイスに関しては、WindowsからメッセージボックスAPIが無くならない限り、ユーザーにとって向上することはないかもしれません。
まぁ例外はメッセージだし説けばいいと考えるのが多すぎるので。
本来はもっとシステム側でリカバリできるはず。またこれを後からやろうとすると、UIも、コードも醜く保守できない物に往々にしてなってしまいますね。しかも機能仕様書やユースケースだけ書いていると、重要な例外処理を見逃してしまうことがあります。(自分の経験)
結局テスト仕様書とかってのは誰に見せるの？誰と合意とるの？ってとこですよね。
＞重要な例外処理を見逃してしまうことがあります。(自分の経験)
それはよくわかります。(^^
たぶんテストをコードでって手順的な部分と、TDDっていう政治的標語的な部分とあるけど、TDDってワードになると政治的な趣になっちゃうからあれなのかな(^^
そっかー、契約による設計(Design by Contract)ね、確かに。TDDでは、Design by Use とか Design by Example などが候補の言葉になっている模様。