壊して育てる、テストの信頼性

AIがコードもテストも書く時代、そのテストは本当に信頼できるのか。テストの偽陰性（検知漏れ）問題に着目し、コードを意図的に壊してテストの信頼性を検証するMutation Testingの手法を紹介します。

Transcript

1. 壊して育てる、 テストの信頼性 Naohisa Yokoyama / 株式会社マイベスト 2026-02-19 @RailsTokyo#3
2. 自己紹介 Naohisa Yokoyama 株式会社マイベスト プロダクト開発部 イネーブリングチーム バックエンドエンジニア 最近は組織全体の内部品質の改善に取り組んでいます。 X : @_shrrk 2
4. mybestと Ruby/Rails 4
5. 生成AI/LLMの活用 全社員を対象とした月額10万円のAIエージェント利用補助制度を導入。 開発はもちろん全社的にAIを積極的に取り入れています。 5
6. そのテスト、本当に信頼していいのか AIエージェントの導入により実装はAIが高速に書いてくれるようになった。 AIは実装と同時にテストも高速で書いてくれる。 でもそのテストが信頼できるかどうかはどう判断すればいいのか。 人間のコードレビュー(遅い) →AIにテストコードをレビューしてもらう(結局AIを信じることになる) →振り出しに戻る。 コードを書く速さではなく、テストの信頼性が開発速度の上限を決める 6
7. そもそもテストの信頼性とは 信頼できるテストは2つの性質を持っている。 正しければ通る — バグがなければテストが成功する 壊れたら落ちる — バグがあればテストが失敗する → 言い換えると、嘘がなく、検出力が高いものが信頼できるテスト。 7
8. 偽陽性と偽陰性 テスト成功（陰性） テスト失敗（陽性） バグがない 真陰性 偽陽性（誤検知） バグがある 偽陰性（検知漏れ） 真陽性 偽陰性はテストが成功してしまうので、気付きにくいのが厄介 8
9. 偽陰性の例 バグがあって実際にレコードが作成されていなくてもテストが通ってしまう。 it "creates a user" do post "/users", params: { user: { name: "Alice" } } expect(response).to have_http_status(:created) end こうなっていれば検知できた。 it "creates a user" do expect { post "/users", params: { user: { name: "Alice" } } }.to change(User, :count).by(1) expect(response).to have_http_status(:created) end 9
10. 偽陰性を検知するには ※信頼性の高いテストについて再掲。 正しければ通る — バグがなければテストが成功する 壊れたら落ちる — バグがあればテストが失敗する であれば、コードを壊してみてテストが落ちるか確かめればいい。 →ここで使えるのがMutation Testingという手法。 10
11. Mutation Testing コードを意図的に壊して、テストが検知できるか確かめる > を < に変える、true を false に変える、条件分岐を削除するなど # 元のコード # Mutation（変異） if user.admin? if !user.admin? grant_access grant_access end end テストが落ちなければ、そのテストは偽陰性を含んでいる可能性が高い。 テストを追加して検出力を上げ、正しく落ちるように改善していく。 →こうして信頼性を育てることができる。 11
12. mutant gem RubyではMutation Testingを実行できる mutant というgemがある。 bundle exec mutant run --use rspec 'User#admin?' 指定したメソッドに対して自動で変異(コードを壊す操作)を生成し、テストで検知 できるか確認する ASTベースで変異を生成している RSpecやMinitestなどと連携して使える GitHub: https://github.com/mbj/mutant gem自体は10年ほど前からあるが、AIの台頭によって再注目されそう…？ 12
13. 実行例: Person#adult? # lib/person.rb # spec/person_spec.rb class Person it 'returns true for age 19' do def adult? expect(Person.new(age: 19).adult?).to be(true) @age >= 18 end end it 'returns false for age 17' do end expect(Person.new(age: 17).adult?).to be(false) end mutantを実行すると、17件の変異のうち2件が生き残ってしまった Mutations: 17 Results: 17 Kills: 15 Alive: 2 def adult? - @age >= 18 + @age > 18 end → age == 18 の境界値テストが不足していたことが分かった。 13
14. @age >= 18 に対して生成される変異（17件） raise | super | （行削除） | nil @age | nil >= 18 | @age > 18 | @age == 18 @age.eql?(18)| @age.equal?(18) | 18 | @age >= nil @age >= 0 | @age >= 1 | @age >= 19 | @age >= 17 @age >= 18 (noop) たった1行のコードに対して17件の変異が生成される。 これを手動で確認するのは現実的ではない。 14
15. mutant のメリット・デメリット メリット ASTベースで精度の高い変異を生成できる OSSなら無料で利用可能 デメリット 実行が遅い (変異ごとにテストを実行するため、フル実行は現実的でない) → インクリメンタルモードで差分だけ検証することで軽減可能 商用利用は有料 ($90/month per developer) 振る舞いを変えたときの挙動をメソッド単位で見るので、コンポーネント間の連携 バグや設計上の問題は検知できない 15
16. まとめ テストもAIが書いてくれる時代において、テストの信頼性をどう担保するかが課題 信頼性の高いテストは嘘がなく、検出力が高いテストである コードを意図的に壊すことで、検出力の低いテストを見つけることができる それらを正しく落ちるように修正することでテストの信頼性を育てることができる 16
17. 参考 https://gihyo.jp/dev/serial/01/savanna-letter/0002 https://github.com/mbj/mutant 17