Who tests the Tests¶
チェック¶
- [ ] 本文を確認した
- [ ] 概要を確認した
- [ ] タグを確認した
- [ ]
inbox/直下へ移行した
概要¶
Go Conference mini in Sendai 2026 の資料。
CI はチーム開発の最低限の約束であり、AI Agent が自己回帰する際の checkpoint にもなる。
一方で test coverage は嘘をつくため、mutation testing によって「テストが本当に意味のある失敗を検出できるか」を検証する必要がある。
Go の -overlay を使った mutation testing 実装も紹介されている。
本文¶
CI は開発サイクルの最低限の約束として説明される。 CI の成功は review 依頼の準備を意味し、CI の失敗は修正対象を示す。 AI Agent 時代には、CI が agent の自己修復ループの checkpoint になる。
品質を担保する手段として、linter / analyzer と test が挙げられる。
Go では go vet、golangci-lint、go fix、go test などがある。
テストは、実装意図を明文化する保証書であり、コードに最も近い client でもある。
しかし coverage だけを目標にすると、指標が目的化する。
100% coverage でも assertion がなければ意味がない。
AI に test を書かせたら t.Skip していた、というような問題も起こりうる。
Mutation Testing は、program の一部を意図的に書き換え、その mutant に対して test を実行し、失敗するかを確認する手法。 演算子反転、条件変更、loop 変更などが例。 test が失敗すれば mutant は killed、test が成功してしまえば survived。 多くの mutant を kill できるほど、test が挙動を検出できていると考える。
ただし mutation testing は実行時間との trade-off がある。 100% killed を目指すのではなく、意味のない mutant は ignore し、対象範囲を考える。
Go 実装では、AST から mutation を生成し、一時 file と overlay.json を作る。
go test -overlay=overlay.json ./... を実行することで、実ファイルを直接書き換えずに mutant を test できる。
overlay は Go 1.16 で導入された仮想的な file replacement の仕組み。
要点¶
- AI 時代ほど CI は品質 checkpoint として重要。
- Coverage は必要だが、それだけでは test の有効性を測れない。
- Mutation Testing は test を test する手法。
- Go の overlay を使うと、実ファイルを変更せず並列に mutation testing できる。