レガシーなプロジェクトやスケジュールに余裕がないプロジェクトでは、テストコードが存在しない・一部しか実装されていないようなケースがあります。そんなプロジェクトにテストコードを導入する際、どういったステップで導入を進めていくべきか。最近業務でそういった推進的なことをする機会があったので、実体験も踏まえて自分の考えを整理します。
0. チーム内でテストについて会話をする
まずやるべきことは対話です。
なぜ現在のコードベースにテストコードがないのか、その経緯からヒアリングする必要があります。この対話フェーズをスキップしていきなり「テストコードがないから実装するぞ！」と意気込んでも、他の開発メンバーから煙たがられる可能性があります。
テストコードがない理由として、私はよく以下の2パターンで場合分けをします。
- テストコードの必要性は理解しているが、なんらかの理由で実装・着手できていない
- テストコードは不要だと考えており、実装していない
前者のように「テストを書きたいけど書けない」の場合、ブロッキングしている事情を取り除くことが目標となります。
後者のようにテストコードの必要性の理解があまりない場合、なぜテストを書くのか？というところから認識を合わせにいく必要があります。
プロジェクトの状況・背景をきちんとヒアリングした上でどういう対話が必要なのかを整理します。
1. まずはド正常系を一本通すテストケースを実装する
前フェーズの対話が終わり、テストコードを実装することに対してチーム内で合意が取れたら、まずはド正常系のテストを一本書くところから始めましょう。異常系やエッジケースなど、細かいテストケースの実装もしたくなりますが、「まずは一本正常系を通すことができた」という成功体験を積むことが重要だと自分は考えてます。
2. 自動テストの実行基盤を構築する
正常系のテストケースが一本実装できたら、CIでテストを自動実行できるようにしましょう。
テストコードは作成することよりも実行することのほうが重要です。そしてその実行は手動実行ではなく自動で実行されるべきです。実行トリガーは様々ですが、代表的なトリガーはGitへのPUSHやプルリク作成時です。
自動実行にはCIを使いましょう。GitHub ActionsやAWS CodeBuildなど、プロジェクトの特性に合わせてCI基盤を選定します。CIの設定は初期構築は少し大変かもしれませんが、一度構築してしまえばその後何度も何度も自動テストが実行されるため投資対効果が高いです。
まとめ
- 対話→正常系一本通す→自動実行できる環境を作る の順に進める
- 最初の対話が一番大事
- CI構築は初期構築の苦労さえ乗り越えれば投資対効果が高い