きっかけ
Cleanシリーズの書籍で知られるボブおじさん(Uncle Bob Martin)のX投稿を見て、気になったのでやってみました。
Before every check-in, I run a suite of tools that cause the AI to improve the code. Those tools are things like test coverage, crap analysis, mutation testing, and acceptance test mutations.
— Uncle Bob Martin (@unclebobmartin) 2026年5月19日
要点は4つ
- テストカバレッジを取る
- カバレッジと複雑度を測定し、両者の掛け合わせスコアであるCRAPスコアを取る
- ミューテーションテストを行う
- 受け入れテストのミューテーションを行う
テストカバレッジを取る
これはその通り受け取れば良さそう。単体テストを整備して、実行し、カバレッジを測定するモニタリングする。 Codecovのようなツールを用いてもいいし、単体テストに備え付けのレポーターを使ってもいいし、GitHubのプルリクエストでCIを走らせて、結果をコメントで追記させても良さそう。
Claude Codeへの指示でテストコードはしっかり書くようにしているつもりだったが、最初に測定したカバレッジは10%そこそこでした。きちんと測定し続けるのは大事！
参考) CLAUDE.mdのテスト関連指示
## 開発手順
- 先にテストコードを作成してTDDで開発すること
- 異常値、偽陰性、偽陽性、境界値、状態遷移を考慮して入出力＆振る舞いのパターンを洗い出し、テストを整備せよ。
- 形骸的なモックによる無意味なカバレッジ向上はNG。
- ホスト環境への副作用や破壊的変更に注意。
- 冪等性を担保し、実行日時や外部状態に依存しない造りにせよ。
- テストを先に書くだけでなく、実装後のリファクタリングも必要ないか確認すること。
CRAPスコアの算出
CRAPは Change Risk Anti-Patterns の略で、複雑なコードかつテスト不足なコードを検出する指標とのこと。
サイクロマチック数(CC)とテストカバレッジをもとに下記の式で算出できる (Understanding CRAP and Cyclomatic Complexity Metrics)
CRAP = CC² × (1 - coverage/100)³ + CC
30以下だと許容範囲。30〜60だと注意が必要。60以上だとリファクタリングの検討をした方が良いという感覚らしい。
ミューテーションテストの導入
ミューテーションテストはコード中の条件式を変えたり、AND/ORの条件式を書き換えた時、テストがどれだけ失敗するかをテストする手法。
以前から面白い考え方だと思ってはいましたが、業務で整備するのはなかなかコストが重いなと思っていました。 AIコーディングエージェントなら疲れず取り組んでくれるので向いている気がします。
受け入れテストのミューテーションを行う
元の投稿は下記の文章でした。
acceptance test mutations
単に受け入れテスト(E2Eテスト)の実施と読んでいましたが、改めて考えると受け入れテスト自体にミューテーションテストの取り組みを入れているのかもしれません。
たとえば
Given ログイン済み When 商品を購入する Then 注文が作成される
を
Then 注文が作成されない
に変えるようなことです。Playwrightとかの実行コードを書き換えることでも同じようなことができるかな?
バグは見つかった?
それぞれは聞いたことがあっても、個別に導入して使えるようにするには一定労力がかかります。 とはいえClaude Codeに頑張らせることで、7万行程度のLaravelリポジトリに1〜2日程度で実用に載せることができました。
- カバレッジを測定してGitHubのPRにコメントを残すところまで
- CRAPスコアを算出して、スコアが高い箇所のリファクタリングやテストの追加を行う
- Playwright CLIを使った主要画面のハッピーパステストを行わせる
導入過程で見つかった不具合は2件ほどでしたが、今後新しく作られるPRの品質を機械的に引き上げることができそうなのは良いなと感じています。
あとは
- リンター
- 型チェック
- セキュリティスキャン
も組み合わせるとより良さそうです。
