シフトレフトテストとは？

シフトレフトテストとは、開発ライフサイクルの早い段階へテストを移し、欠陥が最も安価なときに発見・修正されるようにすることです。

開発のタイムラインが設計からリリースへと左から右に流れるところを想像してください。従来、テストは右端、リリース直前に位置していました。シフトレフトとは、テストを左へ、より早くに引き寄せ、バグが導入された時点の近くで捕まえられるようにすることです。欠陥が早く見つかるほど、修正は安く簡単になります。

遅延コストという考え方

コードを書いている最中に見つかったバグは修正コストがわずかです。同じバグが本番で見つかると、デバッグ、調整、ユーザーへの影響において桁違いに高くつくことがあります。シフトレフトは、欠陥を可能な限り早く、理想的にはコードがmergeされる前に捕まえることで、その曲線に立ち向かいます。

左へ移すとはどういうことか

コードと並行して、あるいはその前にテストを書く（TDD）。
リリース前だけでなく、あらゆるcommitで高速なテストを実行する。
エディタとpre-commitで静的解析とlintingを追加する。
設計上の判断を早期にレビューしテストする。

シフトレフトとCI

継続的インテグレーションはシフトレフトのエンジンです。あらゆるpushで自動的にテストを実行することで、CIは検証を実用上最も早い瞬間、コードが共有された瞬間へと移します。そのフィードバックが速いほど、実効的なテスト地点はさらに左へ移ります。

簡単な例

pre-commit hookやあらゆるpull requestでユニットテストを実行すれば、バグがチームメイトに届く前に捕まえられます。

Testing as early as possible

on: pull_request
jobs:
  test:
    runs-on: latchkey-small
    steps:
      - uses: actions/checkout@v4
      - run: npm test  # runs before review, not after merge

なぜここで速度が重要か

シフトレフトは、早期のテストが高速な場合にのみ定着します。あらゆるpushで遅いスイートが走ると、開発者はそれをスキップするようになり、シフトが台無しになります。テストを高速runnerで並列実行することで早期のフィードバックをほぼ即時に保ち、それが早期テストを実際に実現可能にします。Latchkeyが埋めようとしているのはそのギャップです。

重要なポイント

シフトレフトテストはテストをライフサイクルの早期に移します。
欠陥をより早く検出することは、より安く簡単な修正を意味します。
あらゆるpushでの高速なCIがシフトレフトを実用的にします。