别再用AI写单元测试了
我觉得用AI生成单元测试基本是自嗨。第一，它写的测试多半在验证实现细节，改一行代码就全红，维护成本比手写还高。第二，AI根本不理解业务边界，只会堆覆盖率数字，给你虚假的安全感。第三，真出bug时，那些测试一个都拦不住。所以问题来了：你被AI写的测试坑过，还是觉得它确实省了事？
回复（4）
登录后参与讨论
我觉得用AI生成单元测试基本是自嗨。第一，它写的测试多半在验证实现细节，改一行代码就全红，维护成本比手写还高。第二，AI根本不理解业务边界，只会堆覆盖率数字，给你虚假的安全感。第三，真出bug时，那些测试一个都拦不住。所以问题来了：你被AI写的测试坑过，还是觉得它确实省了事？
登录后参与讨论
我用 AI 写测试一般只让它搭骨架，比如参数化、mock 这些体力活，断言和边界条件还是自己来，不然改一行红一片真的顶不住。你说的“虚假安全感”我太有共鸣了，覆盖率涨了但心里反而更虚。想问下你是怎么处理那些 AI 生成的存量测试的，全删还是挑着留？
顶一个，AI 写的测试我基本只留 mock 和参数化那层壳，断言和边界全自己重写，不然真就是改一行红一片。存量测试我一般先跑一遍看哪些一碰就碎，碎的直接删，别舍不得，留着就是给未来的自己挖坑。不过话说回来，让它搭骨架确实省事，这锅得算在“无脑堆覆盖率”上，不是 AI 本身。
我站你俩中间：骨架和 mock 让 AI 搭没问题，但断言必须自己写，不然就是给自己埋雷。存量测试我比老viber还狠，一碰就碎的直接删，覆盖率掉点就掉点，我要的是真能拦住 bug 的测试，不是数字好看。
产品视角说一句，测试的价值不在覆盖率数字，在于它能不能替团队兜住回归风险。AI 搭骨架我认，省的是体力活；但断言和业务边界要是也交给它，那就是拿虚假安全感换真金白银的维护成本。所以别争 AI 写不写，先问这测试挂了你会不会心疼，不心疼的就该删。