- TDDは1つのボールに集中する
- 「割り込みにさらに割り込みしない」は実践したい
- 「TDDは個人スキル」
- 「価値観をテストにする」作業は技術なので、最初は上手く行かなくても仕方がない
- 普段は一区切りついた所でcommitするため、コミットログからTDDは見えない
- やりすぎて戻るくらいがちょうど良い
- 「守破離」
- 書きたいテストのタイトルだけ書いて、リストアップというのをよくやる
- 悩みすぎてcommitしないより良い
- 後でsquashすれば良いから、細かくても気にしなくてよいのでは?
- リモートワークでは、そのほうが進捗が見えて安心できるかもしれない
- 経緯、思考のログが見えてくる
- issueのコメントをslackのように使って、思考のログを流している
- 問題を噛み砕いて、解決の足跡を残す
- とりあえずでっち上げの定義でコンパイラを黙らせて、アウトラインを考えるのをよくやる
- サブクラスを外側には露出しない部分型として扱うのが面白かった
- テストにしか出てこない型
- TDDと受け入れテストは役割が違う
- テスティングフレームワークは複雑でない方がよい
- テストツールはAPIが変わってはいけない
- 「No API is good API」
- power-assertについて、id:t-wada 氏がテストツールは安定性が重要なので、あえてドッグフーディングはしないと言っていた
- JavaScript Ninjaの極意でも、テストフレームワークを作る章があった
- WebDriverの初期化など。やむを得ない場合の初期化が重要
- RailsのDB関係のテスト。最近はトランザクションで初期化しているので早い
- テストは思いとやる気がでない
- guard 良い
- 自分のいつものやり方との違いが見える。ペアプロ的
- TDD未経験の場合、テストコードを書く分、アウトプットの量が半分になるのはデメリット?
- UIのテストの場合、手入力だと時間が掛かるので、すぐに元が取れる
- ふわふわした議論ではなく、テストの実例で語る
- テストがあれば、それを元に議論ができる
- 複雑なテストでは、あえてシンプルに書く
- 一時的なテストを書いて、最後には消すという技法
- どうテストを悩むか悩むより書く
- 駆動する。TDDはとにかく動き続けられる
- 「前に進んでする」という実感がある
- 明白な実装と仮実装を繰り返しながら書く
- 詰まったら休憩。それでも駄目なら最初からやり直す
- あえて週末にテストを失敗するcommitを入れて、月曜に思い出しやすくする
- 問題を噛み砕けていない?
- Matz曰く「メソッド名が思いつかないということは機能がわかっていない」