想法与洞见

探索 AI 优先开发、编码护栏和可处置架构。

你的测试全过了。变异得分只有40%。以下是你该从存活变异体中读到的东西。

代码覆盖率告诉你很安全。变异测试告诉你,你的测试大多只是摆设。以下是存活变异体如何暴露这一鸿沟,以及如何弥合它。

你的测试全过了。覆盖率报告显示87%。但你的变异得分是40%,一半的变异体还活着。 这个40%不代表你的代码有毛病。它代表你的测试有毛病。覆盖率衡量的是测试运行期间哪些行被执行了。变异测试衡量的是,如果那些行开始做错事,你的测试会不会发现。40%的变异得分意味着,60%本可以被引入代码的 bug 会大摇大摆地通过…

Rust 的变异测试确实能用,但你的编译时间会恨你

cargo-mutants 能找出那些只是假装在验证代码的测试。本文介绍变异测试在 Rust 中的工作原理、它能捕捉什么问题,以及编译时间成本是否值得。

你有 100% 的行覆盖率。每个分支都执行到了。每个函数都被调用了。然后有人在定价逻辑里把一个 改成了 ,跑了一遍测试,全部通过。 这不是理论问题。它真实发生在你的测试执行了代码,却没有真正验证行为的时候。覆盖率衡量的是哪些行被执行了,而不是哪些输出被检查了。变异测试通过故意引入小的…

验证光谱:为什么 AI 编写后端代码最出色

AI 编码遵循一条验证梯度:后端在毫秒内确定性地验证,Web 需要分钟级的视觉回归,移动端受限于物理现实需要数小时。验证速度和确定性沿着这条光谱递减,反馈循环直接决定了 AI 编码在哪里能发挥作用、在哪里会碰壁,决定了AI编码的可行边界。

AI 模型自己写代码并不是最有趣的部分。有趣的是它生成代码之后发生的事情。模型能以多快的速度知道代码是否正确?生成与验证之间的反馈循环有多紧密? 这个循环决定了一切。它决定了模型能否对自己的输出进行迭代。它决定了人类是否可以在不经手动检查的情况下信任输出。它决定了 AI 编码在哪些领域真正有效。…

猴子、机关枪、aimbot:给编程团队的 AI 治理方案

AI 代码治理不是要从初级开发者和 AI 代理手中夺走工具,而是要安装guardrails,让每一发子弹都命中目标而不会造成附带损害。

机关枪已经发到每个人手里了。 AdEspresso 联合创始人、Unkover 首席 AI 官 Massimo Chieruzzi 精准地捕捉到了这一点:"AI 有时让你感觉自己像一只端着机关枪的猴子。"…

变异测试需要跑4小时。团队到底怎么在CI里用它?

大多数团队不会每次提交都跑完整的变异测试套件。以下是工程团队如何在不破坏构建流水线的情况下,真正把变异测试集成进CI的做法。

如果你的变异测试套件需要跑四个小时,恭喜你。你证实了大家早就怀疑的一件事:你的测试套件存在漏洞。 你不可能每次 push 都到 CI 里跑这个。没有哪个团队会这么干。问题不在于你能否承受每次提交花四小时,而在于你能否承受带着“测试通过但实际上什么也没验证”的代码上线。…

单元测试全绿,但你的数据照样消失

Mock 数据库测试验证的是 SQL 语法,而不是数据行能否在崩溃、并发写入或 schema 不匹配时存活。下面介绍如何真实地测试持久化。

如果你在测试中 Mock 数据库,你实际上只是在验证仓库层调用了正确的方法。你并没有测试数据能否在崩溃后存活、唯一约束是否真的会阻止重复数据、或者事务失败时是否会回滚。 这个区别很重要。Mock 的 返回你预设的值。真实的…

恐惧 vs. 碾压:AI 编程的两种现实

AI 编程对能够从任何混乱中恢复的精英团队有效。其他人则只能面对恐惧、失败的 CI 和被放弃的实验。差距不在模型本身。

观察两个团队使用同一个 AI 模型,你会看到两种完全不同的结果。 第一个团队让模型构建一个界面。输出接近但不够准确。样式偏离了 Figma 文件。状态管理触及了不该碰的文件。构建在本地通过但在 CI…

不被 mock action 淹没地测试 Redux

为每个 Redux action 写 mock 会让你的测试变成 changelog 校验器。下面介绍如何用真实的状态流转来测试 store。

如果你写过这样的测试:验证 被调用时传入的 payload 结构完全匹配,那么你的测试会在每次有人重命名常量时崩溃。 这不是在测试你的状态逻辑,而是在测试你的手指有没有敲对字符串。 Redux 测试教程通常以 Jest mock 开头:spy ,断言 action creator 被调用了,断言 type…

AI 编程落地生产环境:为什么大多数团队半途而废

大多数团队尝试 AI 编程,代码上线后被 QA 驳回,然后放弃。问题不在于模型——而在于缺少让 AI 输出变得可信任的护栏。

大多数尝试 AI 编程的团队都遵循相同的轨迹。 他们一开始充满热情。模型在几分钟内生成了功能,他们把它发布了。QA 发现了一个 bug,于是他们发布了修复。QA 又发现了一个 bug,这次在一个本应毫无关联的 module 里。修复涉及十四个文件,QA 又发现了三个新问题。…

100 次测试运行是个谎言:如何真正确定你的 Property-Based Tests 规模

Property-based testing 中默认的 100 个 example 是一种社会妥协,而非统计策略。以下是如何选择与你的信心需求和 CI 预算相匹配的运行次数。

如果你用默认的 100 个 example 来运行 property-based tests,那你两头不讨好。你的 CI 比实际需要更慢,而你仍然没有抓到真正重要的 bug。 这个数字并不神奇。包括 Hypothesis 在内的大多数库默认设为 100,只是因为它是一个看起来保险的整数。但「感觉保险」不是测试策略。…