|
|
|
==利点==
*"Clean code that works." がテスト駆動開発の目標である。が、クリーンでかつ動くという2つのことを同時に考えるのは、場合により非常に困難なものになりうる。そこのためで、テスト駆動開発では、まず動く（テストをパスする）コードを作ることに専念し、次にこれをクリーンに整形する（リファクタリング）ことに専念することで、これを解決する。
*テストのパスにより、進捗が後戻りしないことを確認できる。逆に、Fake ItやTriangulateなど、実装するものの見当がつかなくとも、頭で考え込む代わりに前にコードで具体化して進むことができる（そして、それは実際には考える必要のないものであることが後で分かるかもしれない）。テスト駆動開発は着実に進捗を進めることを可能にする開発方法である。
*設計に関する決定のフィードバックとして、それを具体的にテストコードに記述することによりって、その良し悪しが判断できる。実装に関する決定のフィードバックは、テストの失敗やパスによって通知される。両者とも、採用の決定から短い間隔でフィードバックを得ることができる。
*テスト駆動開発は、あくまで開発のための手法であり、そこで得られるテストは副産物であるが。しかし、その開発手順から、コード本体は、テストをパスさせるために記述されたものである。そのため、理想的なテスト駆動であれば、[[コード網羅率|カバレージ]]は100%になる。欠陥や[[バグ]]は、非常に少ないことが期待される。
*具象的なコードから始まり抽象化するため、適切な抽象化で抑えられる。過度な抽象化はむしろ柔軟性を失わせ、保守のコストもかかる。そこで、具象的なコードから始めて、次第にそれを抽象化していくことで、適切な抽象度で抑えることができる。つまり、現在の仕様に対応すできるだけのシンプルさを保つことで、逆説的に将来の仕様変更への対応が容易になるのである。
== 問題点 ==
|
