前回の話
今更だけどTDD導入（失敗編）
https://qiita.com/ilohas20983/items/b1ca1edbb2ad600a2b9c
いろいろ調べて考えたこと
Q1. 馴染ませるために必要なことって？
TDDをプロジェクトに馴染ませるために必要なことをまじめに考えてみた。
まず、馴染ませるためには工数が見えることが最低条件。でないと誰も作業の承認なんてしない。
工数が見えるためには、A1. 基準と手順が必要になるけど、
手順化が必要なレベルの作業をプロジェクトに新しく馴染ませようとするとすぐ廃れる。
なら、A1. 自動化するしかない。
Q2. 何を自動化すればいいのか？
すぐ思いついたのは、エラーになっているテストがどれかをわかるようにすること。
つまり、A2. テスト実行の自動化とテスト結果の自動出力をすること。
gitlab-ciを利用したテストの自動化や、gradleのプラグインでテスト結果の自動出力はすぐ実現できた。
見えるようにできたでは見に行ってもらうという作業が発生するため、まだ足りない。
gitlab-ciのパイプライン結果＝自動テスト結果となるようにして、
merge request承認時にA2. 必ず目につくようにした。
Q3. どこまで自動テストにするのか？
まずは、Mockなどを利用したA3. ModelのUnitTestのみとするべきだと思う。
IntegrationTestやE2eTestもまとめて導入すると導入効果の計測や本来あるべき姿から離れて実装してしまう恐れがある。
UnitTestに絞るのであれば、指標もコードカバレッジで十分。
結果
上に記載してある仕組みをすべて整えたうえで、前回作成した中身を組み合わせて利用した。
かなり評判は良く、半年以上たつけどメンテナンス不足には陥っていない。
そろそろIntegrationTestやE2eTestを導入してもうまく行きそうかな、といった状態に感じる。
それぞれ何のツールをどのように使っているかの細かい話もかけるといいなと思います。