7 posts
Mutation testing 發現了一個 survivor，但你完全不知道這個 mutation 到底做了什麼。這裡有一個逐步方法，讓你在還沒理解 mutant 之前就能寫出正確的 test。
你的 mutation testing 報告充滿了 survivors，其中至少有一個讓你完全摸不著頭緒。 工具說它在第 47 行把 翻成了 ，或是把整個 conditional block 替換成 ，或是 mutate 了一個你根本不知道正在被測試的 string literal。你把 diff…
為何在整個 codebase 強制套用單一 mutation score 是錯的，以及如何根據實際風險設定各模組的門檻。
在整個 codebase 強制套用單一的 mutation score，是讓團隊討厭寫測試的絕招。 拿 PIT 或 Stryker 跑一個典型的 repo，你會看到同樣的模式：auth 模組只有 40%，string utilities 衝到 95%，ORM 層則卡在 60 幾趴。本能反應是設一個 70%…
Code coverage 告訴你很安全，Mutation testing 卻說你的測試大多是擺設。這篇文章告訴你 surviving mutants 如何戳破這個假象，以及你該怎麼補破洞。
你的測試全過了，coverage report 顯示 87%，但 mutation score 只有 40%，還有一半的 mutants 活得好好的。 這個 40% 不代表你的程式壞了，它代表你的測試壞了。Coverage 衡量的是「測試執行時跑過哪些行」；Mutation testing…
cargo-mutants 能找出那些只會假裝驗證程式碼的測試。以下是 mutation testing 在 Rust 中的運作原理、它能抓到什麼問題，以及編譯時間的成本是否值得。
你已經達到 100% 的行覆蓋率。每個分支都被執行過，每個函式都被呼叫過。然後有人把你的計價邏輯裡的 改成 ，跑了一下測試，全部通過。 這不是理論上的問題。這就是你的測試執行了程式碼，卻沒有真正驗證行為時會發生的事。Coverage 衡量的是哪些行被執行過，而不是哪些輸出被檢查過。Mutation testing…
大多數團隊不會在每次 commit 都跑完整的 mutation testing。這裡告訴你工程團隊如何實際把 mutation testing 整合進 CI，又不會搞爛 build pipeline。
如果你的 mutation testing suite 要跑四小時，恭喜你。你證實了大家早就猜到的事：你的測試有漏洞。 你不會在每次 push 都跑這個。沒有團隊這樣做。問題不是你能不能負擔每次 commit 四小時，而是你能不能承受程式碼測試通過了，卻根本沒有驗證任何東西。 Code coverage…
如果你想讓 AI-generated code 能在正式環境站得住，光靠 code review 不夠。你需要一套從 type constraints 到 mutation testing 與 runtime containment 的分層安全棧。
AI-generated code 最大的危險，不是它總是錯的。 真正危險的是，它經常「看起來已經對得足夠可以 merge」。 這正是風險所在。明顯有問題的 code 往往會被擋住。真正會進正式環境的是那種看起來合理、能過幾個 happy-path tests、卻悄悄削弱關鍵 boundary 的實作。…
Design by contract、property-based testing、mutation testing、model checking 從來不是壞想法。真正的問題是它們長期需要太多專業判斷才能維持，而 AI 正在改變這筆帳。
軟體工程裡有很多方法，你一讀就會覺得「這本來就該這樣做」。 當然應該用 contracts 明確 function 能接收什麼、必須回傳什麼。當然 tests 不該只寫幾個人工挑選的例子，而應該驗證 properties。當然團隊不該把 coverage 當成品質代理，而應該真的去判斷 tests 能不能抓到…