TDD
参考
2つのルール
自動化されたテストが失敗したときのみ、新しいコードを書く
実装コードの重複を除去する
手順
レッドを出す
グリーンにする
リファクタする
テストを通すために発生した重複を除去する
テストケースを列挙するのではなく、まずは思いついたものはToDoリストに突っ込むのね
その中から最も簡単なものを選んでテストにしていく
でも、これ、テストケースが冗長なケースで埋もれないのか #?? 「仕様を明示するためのケース」から、「実装をやっていくためのケース」に降格しそうな感じがある
$5 * 2 = 10とか、書く意味あるのか、というぐらい小さい
本書はかなり極端に小さくやっているが、実際はそこまで細かくやる必要はない
と、書いている p. 10
複雑な問題をやるときはこのぐらい小さくしてみては?という感じ
「小さな変更を行う」とは
なぜ小さい事をジュウしているのかを知りたい
イメージ的には、テストを羅列して、ごちょごちょ実装して、最終的にグリーンになるのと何が違うのかあまりわからない
小さいことの嬉しさを知りたい
どういうテストケースを書けばいいのか
テストケースは最初のステップでいくつぐらい書くのか
1個書いては1個満たし、というのをやっていくのか
思いつく仕様をテストでできるだけ書き出し、実装の経過とともに増やしていくのか
これをした場合、グリーンに到達するまでのステップは増えることになる
またTDDについても、テストを先に書くことがTDDであるという誤解が生じていました。 ref 『テスト駆動開発』.icon p.289
言うほど誤解なん?
mrsekut.iconがTDDを理解していないだけか
完全に誤解しているかもしれない
そもそも本家がどこからどこまでを「TDD」と呼んでるのかわからん
小さく作ることとか、重複除去するとことかも含めるのか否かとか
単体テストから結合テストに移動したから
Is TDD Dead?