テストコードをテストする、ミューテーションテスト。
プロダクションコードを突然変異でコードを書き換えたら(ミューテーション)、テストが失敗してくれるかどうか。
失敗するということは、不具合を検知できたということです。
ミューテーションする箇所を宇宙人として、
という表現です。
サバイブが少ないほどよく、キルされるほど良いのです。
宇宙人を誰も殺せなかった、キルゼロなテストケース。
例えば、以下のようなコードでしょうか?
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
読み込み中...
タグ「テスト」の記事
お仕事先のWebアプリケーションに、Testcontainersを導入運用して数ヶ月経過しました。 良い点と困る点について、書き残しておきます。 前提 簡単な前提として、バックエンドDB・APIとフロントエンドの3層構成のよくあるWebアプ
2026年07月08日
以下で書いた通り、プロダクトコードを写経したテストコードを削除しました。 "こぶりー" ( https://kobliy.vercel.app/ ) という個人ブログを読むアプリのコードです。 https://silverbirder.gi
業務でWebフロントエンドのテストコードを書く際に、どこに何を書くかというのをざっくりと考えをまとめてみます。 前提 Webアプリケーションのプログラムファイルがツリー構造である前提とします。 tree よくあるフィーチャー単位のフォルダ構
2026年06月05日