单元测试（Unit Test）往往是程序员最讨厌写、老板却最喜欢看（覆盖率）的东西。它是保证代码不退化的防线，但手写 Mock 经常占据了开发流程 30% 以上的无聊时间。
借助大模型，这是首批能够彻底被 AI 降维取代的体力活。在 generate_unit_test.py 的工程实践中，我们打通了它的最后一公里。
AI 生成单测的核心痛点
其实你把几行代码丢到 ChatGPT 里，它马上就能给你写出长长的 @Test 运行块。但真正拿到工程里，往往一片爆红。为什么？
- 瞎用技术栈：工程是 JUnit5 + Mockito，它偏偏给你输出旧版的 JUnit4。
- 边界条件不全面：往往只测试了一条正确的
Happy Path。 - 包名路径缺失：没带
import，手动导包耗时严重。
工程级 AI 单测生成框架的构建
我们在程序里，通过给 AI 设置极度严厉的限定，彻底规避了上面的问题。你需要往 Prompt 里死死钉入这些要求：
- 强行锁定测试框架版本：明确指出“你必须且只能使用 JUnit 5 ( Jupiter ) 以及 Mockito 进行测试。断言请使用
Assertions.assertEquals。” - 强制生成边缘测试：不要仅仅针对正常状况，“除了基本的有效数据测试，你还必须覆盖抛出异常（Exception）、传入 Null 或者边界数值为空集合的各种分支。”
- 使用代码隔离标签：要求它只输出 Java 代码不讲废话。
结果往往是惊艳的。特别是当你的后端 Service 依赖了好几个不同的 Dao/Mapper 需要挨个模拟注入数据（Mock）时，大语言模型能无比丝滑地帮你用 @InjectMocks 和 @Mock 填充掉所有的外围脚手架。我们要做的，仅仅是一键运行，并看着一条条绿色的通过图标。
本文是个人学习大模型实战方向的小记，希望对准备入门 AI 开发的大家有所启发。
感谢关注，我会持续更新，欢迎查看相关源码实现与学习记录：
github.com/start007-sm…
