regression test とは何か？
regression test は、変更後も以前動いていた機能が依然として動作することを検証し、以前は良好だった振る舞いが「退行」するバグを捉えます。
新しいコードは古い feature を静かに壊すことがあります。これが regression (退行) です。regression test は、まさにこれを防ぐために蓄積されたチェックの集合であり、今日の変更が昨日の動作していた振る舞いを台無しにしないことを保証します。
何であるか
regression test は、コード変更後も既存の期待される振る舞いが依然として正しいことを確認します。時間とともにプロジェクトはこれらの大きなスイートを蓄積し、多くの場合、これまでに修正した各バグに対して追加された特定のテストを含むため、同じバグが静かに戻ることはありません。
regression test はどう増えるか
一般的なプラクティスは次の通りです。バグを修正するとき、まずそれを再現するテストを書きます。そのテストは修正前に失敗し、修正後に合格します。それはその後 regression test として永久にスイートに残るため、誰かがバグを再導入すると即座に捉えられます。
例
割引計算のバグが修正されます。修正する前に、開発者は正しい割引後の合計を検証するテストを追加します。数か月後、無関係な refactor が誤って間違った計算を再導入しますが、regression test が CI で失敗し、リリース前にそれを捉えます。
CI への組み込み方
regression test は通常、各変更で自動スイートの一部として実行されるため、再導入されたバグは問題のコミットの数分以内に捉えられます。スイートは大きくなり得るため、チームはフィードバックを速く保つために runner 間で並列化することがよくあります。
なぜ自信を築くか
優れた regression スイートは、チームが恐れずにコードを変更できるようにするものです。以前動いていたものを壊せばテストが教えてくれると分かっているので、積極的に refactor できます。このセーフティネットが、CI/CD の目標である頻繁で自信のあるリリースを可能にします。
重要なポイント
- regression test は以前動いていた振る舞いが依然として動作することを保証する。
- 修正したバグごとにテストを追加することで、それが戻るのを防ぐ。
- 強力な regression スイートは、チームが自信を持ってコードを変更できるようにする。