TDDについて
自動テストのプラクティスが始まりました。その中でTDDについて学習したのでまとめてみました。
TDDとは何か
テスト駆動開発のことです。テストファーストで開発を進め、コードの追加や変更を行い、合わせてリファクタリングによる設計改善を行います。
TDDの流れ
テストリストとして仕様を整理する
リストに基づき、これから書くコードに対するテストを書き、失敗することを確認する(RED)
テストを通すための最低限のコードを追加して、テスト結果を失敗→成功にする(GREEN)
1~3を繰り返してコードが増えてきたら適宜リファクタリングを行う
目的
すばやいFBの確保
実装が問題なく上手くいっているかを確認できます。テストが失敗することで、テストが動いていることを確認でき、テストが成功すれば、追加したコードが正しく実装されていることが確認できます。
コード量が増えてきた際には都度リファクタリングを行い、テストが成功することをチェックすることでバグや副作用の混入を防止します。
設計改善
テストファーストにより、実行フローなどの細部に注意を奪われる前にインターフェースや実装のふるまいの適切性について検討できるようになります。結果的に、保守性に優れたインターフェースの実装や仕様の抜け漏れの検出ができるようになります。
ユニットテストの確保
回帰テストとして継続的インテグレーションに組み込むと、テストファーストやリファクタリングの起点となるテスト成功状態を維持しやすくなります。またテストコードを追加することで、網羅的なバグ出しや機能的な保証を行うユニットテストを容易に得ることができます。(が、純粋なTDDにおけるユニットテストは目的が異なるため、そのままの転用はできないので注意です。)
このユニットテストは、製品コードの仕様やふるまいをわかりやすく示しているため、テストコード自体が一種の仕様書になります。
ユニットテストとは
クラスやメソッドを対象とした、システム内の最小部品のテストのことです。
テストは自動化することで、複数のテストケースを漏れなく確実に実行できるようになります。
TDD三原則
失敗するテストより先にコードを書かないこと。
テストケースのコンパイルが通り、適切に「失敗」するまでは、次のテストケースを書かないこと。
全テストケースが成功するまで、次のコードを書かないこと。
