テストコードをテストする、ミューテーションテスト。
プロダクションコードを突然変異でコードを書き換えたら(ミューテーション)、テストが失敗してくれるかどうか。
失敗するということは、不具合を検知できたということです。
ミューテーションする箇所を宇宙人として、
という表現です。
サバイブが少ないほどよく、キルされるほど良いのです。
宇宙人を誰も殺せなかった、キルゼロなテストケース。
例えば、以下のようなコードでしょうか?
function add(a: number, b: number) {
return a + b;
}
it("1 + 2 は 3 になる", () => {
// 実行しているだけで、検査していない
add(1, 2);
});このテストケースは、何もキルしません。
これは極端な例ですが、テストコードを見ているとたまにこういう どのような変異をしても絶対成功するテスト いうのがあります。
キルゼロなテストケースは、必ずPASSする計測数値上 水増しするので 確認が必要です。
ただ、以下のような場合は必ずしもキルゼロではありません。
function add(a: number, b: number) {
return a + b;
}
it("足し算できる", () => {
expect(add(1, 1)).toBe(2);
});a+b を a*b に変異してもキルしません。
a-b に変異するとキルします。(1-1で0になるので、2ではない)。
ミューテーションテストでキルゼロなテストコースは、プログラムミスを防げていない冗長なものです。
適宜見直す必要がありそうです。
-
s※ ログイン不要で投稿できます。
※ 同じブラウザから投稿を削除できます。
0
読み込み中...
タグ「テスト」の記事
個人開発(趣味)レベルですが、テストに対するスタンスについて簡単に書きます。 コードレビュー 物量に圧倒されるプロダクションコードとテストコードをレビューするのは、 書く工程が減ったため読む深みが浅くなっています。 DIPやインターフェース
2026年10月03日
Testcontainers + Playwright + Cucumber.js による受け入れテストを、公私ともに活用しています。 運用していて気づいた点について、また書き残そうと思います。 開発PR単位でE2Eテスト これはTestc
2026年09月07日
お仕事先のWebアプリケーションに、Testcontainersを導入運用して数ヶ月経過しました。 良い点と困る点について、書き残しておきます。 前提 簡単な前提として、バックエンドDB・APIとフロントエンドの3層構成のよくあるWebアプ
2026年07月08日