要做的第一件事：描述准确需求。这里，我个人是倾向于手动将这些需求拆成一个个小需求，而不是利用 LLM 去自动拆分
然后需要明确测试的种类：
- 单元测试（Unit Test）：验证每个类的内部逻辑
- 工具：JUnit, Mockito
- 集成测试（Integration Test）：核心目标是测试多个组件协同工作的能力，这是个非常宽泛的概念。
- E2E 测试本质上也是一种最大范围的集成测试。
- 切片集成测试 (Slice Integration Tests)：验证特定层的集成。比如：
@WebMvcTest + MockBean(测 Web 层)，@DataJpaTest + Testcontainers(测数据层)。- E2E 测试（End to End Test）：端到端测试，。核心目标是验证“关键用户故事 (Critical User Stories)”或“快乐路径 (Happy Paths)”的全链路贯通
- 启动成本高，运行速度慢
- 这也是个宽泛的概念，前端的 Playwright 和后端
@SpringBootTest都可以用做 E2E 测试
这里我们可以发现：不同的测试种类、术语其实很混乱，没必要纠结我们在做什么测试。
下面 E2E 测试和集成测试我就都叫集成测试了。
另外，测试代码本身也是代码，也需要维护，也会引入更高的复杂度，对于不同的要求的业务，需要我们进行取舍。做个参考：sqlite 官方宣称，其测试代码行数是实际代码的 590 倍。
As of version 3.42.0 (2023-05-16), the SQLite library consists of approximately 155.8 KSLOC of C code. (KSLOC means thousands of "Source Lines Of Code" or, in other words, lines of code excluding blank lines and comments.) By comparison, the project has 590 times as much test code and test scripts - 92053.1 KSLOC.
下面是我个人的意见：
- 对于不复杂的、不重要的业务，即使是 vibe coding，也不要写单元测试，可以少写甚至不写单元测试，多写集成测试
- 多写集成测试，测试快乐路径。对于你预料到后面需要多次重构的代码（vibe coding 写出来的代码质量都不高）：才需要写能包含所有异常的集成测试
- 和所有 vibe coding 涉及的领域一样，对于你不了解的测试方法（或者说测试起来很麻烦的，你都不知道怎么测试的）业务，就不要硬着头皮先写测试了，先写业务代码，再根据代码未来是否需要重构，再决定是否写测试
- 测试代码本质上就是让机器替代人进行测试，如果测试代码写起来很麻烦，可以考虑让人手动测试 LLM 重构的代码是否实现了需求，这里需要权衡