TDD で出来上がるもの

さかもと画伯曰く、 「TDDとTDLとは違う。」 …それでつらつら考えた。

TDD ( テスト駆動開発 ) で出来上がるもの。 っていうか、 成果物?。
# つれづれなるままに書くので、 いきなり信じてはいけません  f(^^;

・ クラスやメソッドに対する、 厳密な外部仕様書。 ( テストコードのことね )
※ ソフトウェアの仕様書として正確なのかどうかは、 保証されません。 f(^^;

・ クラスやメソッドに対する、 必要十分なテスト。
※ ソフトウェアテストの経験が浅い開発者が作った場合は、  保証されません。 f(^^;

・ 厳密な外部仕様書を過不足なく満たす、 製品コード。
※ テストカバレッジのことを理解していない開発者が作った場合は、 保証されません。 f(^^;

・ リファクタリングされた、 美しい構造。
※ ソフトウェアの美しい構造に造詣の浅い開発者が作った場合は、 保証されません。 f(^^;

…ん～っと、 とりあえずそんなとこ? f(^^;

そうそう。 TDD では、 これらを長いタイムスパンで見れば、 同時並行開発します。 でも、 短いタイムスパン ( 数分とか数十分とか ) では、 どれか一つしか考えません。 やっつけねばならない問題の範囲を狭くシンプルにしてやって、 考えることもシンプルにしてやります。 ( …って、 これも、 分割・統治のモノ作りに慣れてないとダメか f(^^; )

複雑なことをいっぺんにたくさん考えるのは苦手だという人 ( 私とか f(^^; ) には、 ピッタリなやり方だと思います。  また、 コードが出来上がった後で、 やれ仕様と違うだの、 やれバグってるだのと言われて、 ぐじぐじと手離れしてくれないのは嫌いな短気な人 ( 私とか f(^^; ) にも、 向いてると思います。

ついでに。 テストは仕様書 ( スペック ) から作るもんです。 出来あがったソースコード ( 設計図 ) から作るもんじゃありません。 そんなことやったら、 出来上がったモノに引きずられて、 大甘なテストになっちゃいます。 ( 出来上がったモノを見て、 「あ、 しまった、 抜けてた」 ってのは往々にしてありますけど f(^^; )
これ、 ひょっとすると、 機械設計屋さんとソフト開発屋さんの、 大きな意識の違い?

それに、 どんなテストをされるのか明確にされてなかったら、 機械設計屋さんは強度計算ひとつ出来やしません。
また、 テストのために、 例えば、 部品を測定器に固定するためのタブ ( 出っ張り部 ) を設計図に盛り込むこととか、 当たり前のことです。 テスト出来なきゃ、 その部品を納品できませんから。

え?  機械設計屋さんの世界では、 テストは簡単に作れるのか、 って?
はい、 簡単です。 ( ソフトウェアに比べれば。)
なんせ、 毎回、 作るものはおおむね同じようなもんですから。 ( ソフトウェアに比べれば。)

比べると、 ソフトウェアのテストを作るのは、 難しいです。
毎回、 まったく違うモノを作ることが多いです。 どんなテストをすればよいか、 合格ラインをどの程度にすればよいか、 いまのところ、 毎回手探りで進むしかありません。 いっぺんに完璧なテストを用意しようというのは、 人間ワザでは不可能でしょう。
そこで、 仕様からラフなテストを作ってみて、 検証し ( つまり、 それに見合う実装を書いてみて )、 テストを追加したり修正したりしていくことで、 テストの精度を上げてくのがいいんじゃないかしらん。
なので、 テスト駆動開発では、  テストも同時並行で開発するのです。