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

==利点==

*"Clean code that works." がテスト駆動開発の目標である。しかし、最初からきれい(Clean)かつ動く(Work)コードを書くのは困難である。そこで、テスト駆動開発では、まず動く（テストに通る）コードを作成し、次にこれをリファクタリングすることできれいなコードに整形する。

*コードがテストに通ることにより、手戻りが発生しないことを確認できる。逆に、Fake ItやTriangulateなど、実装するものの見当がつかなくとも、頭で考え込むのではなく、コードを書くことで具体化していきながら、開発を進めることができる（そして、それは実際には考える必要のないものであることが後で分かるかもしれない）。テスト駆動開発は着実に開発を進めることができる開発手法である。

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

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