テスト駆動開発を読んでみた
詰み本になっていたテスト駆動開発を改めて読んでみました
やっぱり、読んでいて非常にためになる本でした。
第1部 多国通過
第1章 仮実装
最初はテストを通すための仮実装でいい。
まずは欲しい振る舞いを書き起こすこと。
TDDのリズム
1 まずはテストを一つ書く
2 すべてのテストを走らせ、すべて成功することを確認する
3 小さな変更を行う
4 すべてのテストを走らせ、すべて成功することを確認する
5 リファクタリングを行なって重複を除去する
第2章 明白な実装
答えがそのままわかるなら悩まずに正解を書く
TDDは次の流れを回します
- Red：失敗するテストを書く
- Green：テストを通す最小の実装を描く
- Refactor：設計を整える
Greenの作業が明白な実装
第3章 三角測量
リファクタリングの方向性に迷った場合、テストコードを追加することで、方向性を決めやすくなる。
複数のテストケースを使って、正しい実装を測量のように浮かび上がらせる方法
第4章 意図を語るテスト
テストとは仕様書であり、会話であり、設計そのものだ。
・意図を語るという表現はテストコード自体がドキュメントとしての役割を果たすべきであり、そのテストが何を保護しようとしているのか？
・どういう振る舞いを期待しているのかという規範を示している。
・将来の保守者が自信を持ってリファクタリングや機能追加を行えるようにテストの目的（ビジネスロジック上の重要な制約、境界値条件など）を明確に表現すること。
・意図を持って書くと意図を語るテストの違いは意図を持って書くかは出発点であり、意図を語るテストは到達点。
第5章 原則を破る時
短い期間だけ速度が設計よりも重要だからだ。
コピペで似たような役割のクラスを作ってもリファクタリングで解消することができる。
やぶったほうがいい理由
・仕様が曖昧すぎて、テストが書くことが不可能なとき
・コードを書いてプロトタイプを作らないとステークホルダーが何が欲しいかを理解できない
・テストが足枷になり、学習サイクルが遅くなる
・UI/UXなど変化が激しい領域
・UIロジックは仕様変更が多く、テストがメンテナンスコストを上回る
・UIテストは壊れやすい
・既存コードの大規模リファクタリング
・テストを書こうとすると準備が膨大
・まずコードをテストできる状態にする必要がある。
・緊急性の高いバグ修正
・落ち着いてから通常手順に戻す
・PoC
・捨てるコードなので。
第6章 テスト不足に気づいたら
・気づいた時にテストを書こう
・テスト不足は使用の曖昧さへの警告
第7章 疑念をテストに翻訳する
・疑念をテストに翻訳する
・疑念があったら、テストを書いて払拭する。
第8章 実装を隠す
・テストはあくまでも振る舞い（仕様）を確認するだけにする
・テストが実装依存だとリファクタリングができなくなる。
・中のコードを少し変えるだけでテストが壊れる
・テスト修正が大量に発生
・テストの価値が下がる
・テストは仕様のドキュメントとしても機能するためどう振る舞うべきかが伝わることが重要
第9章 歩幅の調整
・テストを実装しておくことによって、小さな調整だけでなく、比較的大きめな調整にも対応可能である。
・歩幅が大きすぎると複雑化し小さすぎると停滞する。
・歩幅の調整には経験と感覚が必要