「テスト駆動開発」の版間の差分

==利点==

*"Clean code that works." がテスト駆動開発の目標である。クリーンでかつ動くという２つのことを同時に考えるのは、場合により非常に困難なものになりうる。このため、テスト駆動開発では、まず動く（テストをパスする）コードを作ることに専念し、次にこれをクリーンにする（リファクタリング）ことに専念することで、これを解決する。

*テストのパスにより、進捗が後戻りしないことを確認できる。逆に、Fake ItやTriangulateなど、実装するものが検討がつかなくとも、頭で考え込む代わりに前にコードで具体化して進むことができる（そして、それは実際には考える必要のないものであることが後で分かるかもしれない）。テスト駆動開発は着実に進捗を進めることを可能にする開発方法である。

*設計に関する決定のフィードバックとして、それを具体的にテストコードに記述することによりその良し悪しが判断できる。実装に関する決定のフィードバックは、テストの失敗やパスによって通知される。両者とも採用の決定から短い間隔でフィードバックを得ることができる。

*テスト駆動開発はあくまで開発のための手法であり、そこで得られるテストは副産物であるが、その開発手順からコード本体はテストをパスさせるために記述されたものであるため、理想的なテスト駆動であればカバレージは100%になる。欠陥や[[バグ]]は非常に少ないことが期待される。

*具象的なコードから始まり抽象化するため、適切な抽象化で抑えられる。過度な抽象化はむしろ柔軟性を失わせ、保守のコストもかかる。現在の仕様に対応するだけのシンプルさを保つことで、逆説的に将来の仕様変更への対応が容易になる。