TDD
step 1. テストリストを作る
これが設計が実質interfaceの設計に当たるので重要であることがわかるmrsekut.icon
step 2. 1つテストを書く
step 3. テストを成功させる
step 4. 必要に応じてリファクタリングを行う
step 5. テストリストが空になるまでstep2に戻って繰り返す
参考
以下のようなものをTDDと呼ぶことがある
自動テストを書くこと
テストコードを実装よりも前に書くこと
これはTDDの1要素であって、十分条件ではない
前に↓これを読んだときにも同じことを思ったmrsekut.icon
2022年に読んだときのメモ
またTDDについても、テストを先に書くことがTDDであるという誤解が生じていました。 ref 『テスト駆動開発』.icon p.289
言うほど誤解なん？
そもそも本家がどこからどこまでを「TDD」と呼んでるのかわからん
小さく作ることとか、重複除去するとことかも含めるのか否かとか
https://www.youtube.com/watch?v=Q-FJ3XmFlT8&t=1145s
見てわかるテスト駆動開発
テストケースを列挙するのではなく、まずは思いついたものはToDoリストに突っ込むのね
その中から最も簡単なものを選んでテストにしていく
でも、これ、テストケースが冗長なケースで埋もれないのか #?? 「仕様を明示するためのケース」から、「実装をやっていくためのケース」に降格しそうな感じがある
$5 * 2 = 10とか、書く意味あるのか、というぐらい小さい
本書はかなり極端に小さくやっているが、実際はそこまで細かくやる必要はない
と、書いている p. 10
複雑な問題をやるときはこのぐらい小さくしてみては？という感じ
「小さな変更を行う」とは
なぜ小さい事をジュウしているのかを知りたい
イメージ的には、テストを羅列して、ごちょごちょ実装して、最終的にグリーンになるのと何が違うのかあまりわからない
小さいことの嬉しさを知りたい
どういうテストケースを書けばいいのか
テストケースは最初のステップでいくつぐらい書くのか
1個書いては1個満たし、というのをやっていくのか
思いつく仕様をテストでできるだけ書き出し、実装の経過とともに増やしていくのか
これをした場合、グリーンに到達するまでのステップは増えることになる
単体テストから結合テストに移動したから
Is TDD Dead?