4 posts
Property-based testing 預設跑 100 個範例是一種社交妥協，而非統計策略。以下是根據你的信心需求與 CI 預算來選擇執行次數的方法。
如果你用預設的 100 個範例來跑 property-based tests，那你等於同時承受了兩種壞處。你的 CI 比實際需要還慢，而且那些真正重要的 bug 你還是抓不到。 這個數字沒有什麼魔力。大多數函式庫，包括 Hypothesis 在內，預設設成 100…
範例導向的測試只涵蓋你想得到的輸入。Property-based 測試會產生隨機資料、檢查不變條件，並將失敗縮減到最小的反例。
你寫了一個 函式。你用 和 測試它。通過了。你發布出去。 有個使用者傳入了一個單元素的 slice。你的函式把它遺漏了。他們開了一個 issue。你盯著測試檔案，納悶自己怎麼會漏掉這麼明顯的東西。 你之所以漏掉，是因為範例導向的測試只能抓到你預期中的 bug。測試套件裡的每一個…
如果你想讓 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 能不能抓到…