回帰テストとは？

回帰テストは、変更後に既存のテストを再実行し、以前は動作していた機能が壊れていないことを確認します。

回帰とは、変更によって以前は動作していたものが壊れることです。回帰テストは、正しいと分かっている振る舞いを捉えたテスト群を維持し、コードが変わるたびにそれらを実行することで、これを防ぎます。これはテストの種類というより目的です。現在が進化する中で過去を守ることです。

回帰とは何か

回帰は、新しい作業、機能、修正、リファクタリングが、既存の振る舞いを不注意に壊したときに発生します。回帰が厄介なのは、開発者が新しい変更に集中しており、古い部分を再確認しようと思わないことがあるからです。自動テストが彼らの代わりに記憶しておいてくれます。

回帰スイート

時間とともに、あらゆるバグ修正や機能が、正しい振る舞いを固定するテストを残していきます。これらが集まって回帰スイートを形成します。よい習慣は、修正するバグごとに回帰テストを追加することです。そうすれば同じバグが二度と静かに再発することはありません。

簡単な例

丸め処理のバグを修正した後、壊れていたまさにそのケースに対してテストを追加します。そうすれば、将来それを再び持ち込む変更があった場合、すぐに失敗します。

A regression test for a fixed bug

test("rounds 2.005 correctly (was a bug)", () => {
  expect(round(2.005, 2)).toBe(2.01);
});

スイートを健全に保つ

修正するバグごとに回帰テストを追加する。
意図した振る舞いをもはや反映していないテストは削除または更新する。
変更のたびに実行できるよう、スイートを高速に保つ。
不安定な回帰テストは背景ノイズではなくバグとして扱う。

回帰テストと CI

CI は主に、push のたびに回帰テストを自動的に実行し、壊れを数分以内に検出するために存在します。スイートが大きくなるにつれ、高速な runner で並列化することで完全な回帰パスを迅速に保ち、一時的な不安定さを自動リトライすることでシグナルの信頼性を保ちます。この速度と信頼性こそ、Latchkey の runner が提供しようとしているものです。

重要なポイント

回帰テストは、変更後も古い機能が引き続き動作することを確認します。
各バグに対して回帰テストを追加し、そのバグが二度と静かに再発しないようにしましょう。
CI は変更のたびに回帰スイートを自動的に実行します。