内容
定義
-
自動化されたテストが失敗した時のみ新しいコードを書く
-
重複を除去する
TDDのゴール
-
動作するきれいなコード(Clean code that works)
スコープ
-
レッド・グリーン・リファクタリングの進め方
Red
-
コンパイルエラーになるところから始めてもいい
-
汚くてもいいのでGreenに持っていく
Green
-
assertして意図通りであることを確認
Refactor
-
必要であれば行う
-
プロダクトコードだけでなくテストコードもリファクタリングの対象になる
-
設計もここで見直す
ライブコーディング時のメモ
-
細かい粒度でテストを実施することで過剰な設計を防げる
-
ParameterizedTestアノテーションを使用することで引数を柔軟に変更したテストができる(JUnit4からあるがJUnit5から利用が楽になった)
-
リファクタリング後のテストコードが動作しているかプロダクトコードをわざと壊してレッドになることを確かめる(テストのテスト)
-
フィードバックサイクルが短いのでバグを埋め込んでからバグの発見までのスピードが速くなる
-
テストコードから仕様を読み取れるようにしておく(ParameterizedTestのパラメータを増やすか、メソッドするかの基準もこれ)
-
テストコードを記載している時に仕様の漏れ(-1の場合は何が期待値?等)に気が付ける。テストコードを記載すれば仕様が仕様になる
-
ドキュメントは修正忘れるけど、テストは落ちるから修正が必要になる
-
MethodSourceアノテーションでメソッドでテストデータを生成できる
-
JUnitにはcoverageを計測しながらテストすることができるが、テストがassertionされていなくてもテストコードで通っていれば100%になってしまう
-
coverageが100%だからといってテストが"十分"とは言えない
-
"TDD"と"自動テスト"は解決したい問題が別
TDDが解決したい課題
-
十分なテストが書かれない
-
後からテストを書くと、必要パターンが漏れてしまうことが多い
-
-
テストを書こうとした段階で、テストを書きにくい設計であることに気が付く
-
自然と高凝集・低結合なクラスを書くようになる(テストしずらいクラスは責務過剰だったり依存関係が多い)
-
感想
-
メリットは分かったので実際にTDDでテストコードを書いてみるぞ
-
精神的に安心できる(動かしてみるまでわからないを避けられる)というのが良いと思った
-
フィードバックサイクルを短くするというのは設計/実装だけでなくレビューなどにも当てはまると思うので仕組みを作って取り入れていく