4 posts
Property-based testing 中默认的 100 个 example 是一种社会妥协，而非统计策略。以下是如何选择与你的信心需求和 CI 预算相匹配的运行次数。
如果你用默认的 100 个 example 来运行 property-based tests，那你两头不讨好。你的 CI 比实际需要更慢，而你仍然没有抓到真正重要的 bug。 这个数字并不神奇。包括 Hypothesis 在内的大多数库默认设为 100，只是因为它是一个看起来保险的整数。但「感觉保险」不是测试策略。…
基于示例的测试只覆盖你想得到的输入。property-based testing 生成随机数据，检查 invariants，并将失败 shrink 到最小反例。
你写了一个 函数。你用 和 测了它。测试通过。你发布了。 用户传入了一个单元素切片。你的函数把它漏掉了。他们提了 issue。你盯着测试文件，想不通这么明显的问题自己是怎么漏掉的。 你漏掉它，是因为 example-based testing 只能抓住你提前预料到的 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 能不能抓到…