TDDのテストはテストなのか?

テスト駆動開発のテストは、テストか?-TDD から BDD へ – An Agile Way [ITmedia オルタナティブ・ブログ]
最近TDDのテストコードは契約による設計での契約書なんだよなぁと考えていたりする。
あと、GUIのデザインを本格的に始まる前に、機能試験仕様書を書いてしまう、特に例外処理の試験を書いてしまうのも有効かなと思ったり。後付で醜くしてしまうより、システムとしてユーザーに対してリカバリー出来る(してもらえる)部分が大きい気がする。

4 thoughts on “TDDのテストはテストなのか?”

  1. 大規模プロジェクトに全面的に適用したことはありませんが、あきらかにすらすら読めるのは”あなただから”ってのが多すぎるように思います。
    実際のユーザさんとの温度差が激しすぎるのは私だけでしょうか。

  2. TDDのテストコードに関しては、開発者が読む物なで、その中で読める物なら良いでしょう。(そもそも開発者が読めないテストコードを書く人間の書くコードって言うのは。。)
    また、ユーザーインターフェイス、特に例外処理に関するユーザーインターフェイスに関しては、WindowsからメッセージボックスAPIが無くならない限り、ユーザーにとって向上することはないかもしれません。
    まぁ例外はメッセージだし説けばいいと考えるのが多すぎるので。
    本来はもっとシステム側でリカバリできるはず。またこれを後からやろうとすると、UIも、コードも醜く保守できない物に往々にしてなってしまいますね。しかも機能仕様書やユースケースだけ書いていると、重要な例外処理を見逃してしまうことがあります。(自分の経験)

  3. 結局テスト仕様書とかってのは誰に見せるの?誰と合意とるの?ってとこですよね。
    >重要な例外処理を見逃してしまうことがあります。(自分の経験)
    それはよくわかります。(^^
    たぶんテストをコードでって手順的な部分と、TDDっていう政治的標語的な部分とあるけど、TDDってワードになると政治的な趣になっちゃうからあれなのかな(^^

  4. そっかー、契約による設計(Design by Contract)ね、確かに。TDDでは、Design by Use とか Design by Example などが候補の言葉になっている模様。

コメントを残す