【ツール活用|実務向け】CI/CDでカバレッジ閾値を強制し、プロジェクトの「腐敗」を防ぐ実装術

導入

開発プロジェクトが長期化するにつれ、避けられない課題が「テストカバレッジの低下」です。新機能追加のスピードを優先するあまり、テストが書かれないコードが蓄積されると、リファクタリングの難易度が上がり、バグの温床となります。本記事では、CI/CDパイプラインにおいて「カバレッジの閾値」を強制し、システム的にコード品質を担保するプラクティスを解説します。

基礎知識

カバレッジ(Code Coverage)とは、テストコードがプロダクトコードのどれだけを網羅しているかを測定する指標です。一般的には「行カバレッジ(Line Coverage)」が用いられます。
CIゲート(CI Gate)とは、ビルドプロセスにおいて一定の品質基準を満たさない場合に処理を中断させる仕組みのことです。閾値を設定することで、「前回よりもカバレッジが低いコードはマージさせない」といった運用が可能になり、チーム全体にテストを書く文化を強制的に根付かせることができます。

実装/解決策

今回は、多くの開発現場で利用されている「Jest(JavaScript/TypeScript)」と「GitHub Actions」の組み合わせを例にします。jest.config.jsで閾値を定義し、CI上でテストを実行する際にその基準を満たしているかチェックします。

サンプルプログラム

まず、プロジェクト直下の jest.config.js にて、最低限守るべきパーセンテージを設定します。

// jest.config.js
module.exports = {
// カバレッジ計測を有効化
collectCoverage: true,
// 測定対象のファイルを指定
collectCoverageFrom: [‘src//.{js,ts}’],
// 閾値の設定(全ファイル平均で80%以上を必須とする)
coverageThreshold: {
global: {
branches: 80,
functions: 80,
lines: 80,
statements: 80,
},
},
};

次に、GitHub Actionsのワークフローファイルです。

.github/workflows/ci.yml
name: CI
on: [push, pull_request]

jobs:
test:
runs-on: ubuntu-latest
steps:

  • uses: actions/checkout@v3
  • name: Install dependencies

run: npm install

  • name: Run Jest

# カバレッジが閾値を下回ると、Jestは終了コード1を返し、ビルドが失敗します
run: npm test

応用・注意点

現場で導入する際、最も陥りやすい罠は「既存コードの低カバレッジ」です。いきなり高い閾値を設定すると、既存のビルドが全て失敗してしまいます。

1. 段階的な導入
まずは「現状のカバレッジを維持する」設定から始め、四半期ごとに少しずつパーセンテージを引き上げる運用が現実的です。
2. 特定ディレクトリの除外
テストが困難な設定ファイルや、自動生成されたコードはカバレッジ対象から除外(coveragePathIgnorePatterns)し、ビジネスロジックの品質確保に集中しましょう。
3. 開発者体験(DX)への配慮
閾値エラーでビルドが落ちた際、開発者が「どこをテストすれば良いか」すぐに判別できるよう、CIのログにカバレッジレポートのHTMLを出力し、Artifactsとして保存する設定を追加することをお勧めします。

システムによる強制は、個人の意識に頼らない最強の品質担保策です。ぜひ明日からのCI運用に取り入れてみてください。

コメント

タイトルとURLをコピーしました