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

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