文章：https://wiki.c2.com/?TestDrivenDevelopment
这是一篇关于测试驱动开发的wiki和讨论。
测试优先设计迫使你真正思考你要做什么。它让你摆脱 "当时看起来是个好主意 "的编程方式。
非常赞同这个观点，因为我经常在任务还不是很清楚的时候就开始编写功能代码，然后反复推翻之前花费大量时间，还觉得很牛啤的代码。最后造成进度缓慢，代码耦合度太高照成后期修改代码的认知负担很重。
解决该问题的有效方法就是：先编写测试用例
该方法尤其适合搭配AI代码助理的编程环境，因为在使用AI进行重构时，可以直接使用测试用例来检查AI的代码，减少人工view的情况，而且有些AI还可以自动运行测试用例来检查生成的代码，效率非常高！
在和AI沟通时，最难的部分其实是将功能表达清楚，而编写测试用例就是一种高效的表达方式
总结下测试驱动开发（TDD）的基础流程，通常遵循“红-绿-重构”的循环：
-
编写失败的测试（红）:
- 在开始实现新功能之前，首先编写一个测试用例。这个测试用例应该验证你想实现的功能。
- 因为功能尚未实现，这个测试会失败（红色）
-
实现代码（绿）:
- 编写最少量的代码使得测试通过。
- 这个阶段关注让测试通过，而不是优化或引入复杂性。
-
运行测试并确认通过（绿）:
- 运行测试确保所有相关测试用例都能通过。
- 如果有任何测试未通过，需要回到步骤2进行调整。
-
重构:
- 在确保所有测试通过后，重构代码以改善其结构、可读性和维护性。
- 此时保持功能不变，确保重构后运行的测试依然通过。
-
重复循环上述步骤
- 根据需要添加新的功能或改进，返回第一步开始新的循环，编写新的测试用例。
在TDD中，首个测试通常是功能测试，对某个功能进行验证，确保它们按照预期工作，待功能确定后，可以编写更细致的单元测试，对具体的方法或类进行测试，而随着开发进展，有可能需要编写集成测试和系统测试，以验证不同模块之间的互动或整个应用的行为。
注意，并不是写完一个功能测试马上写单元测试，而是写完一个模块的所有功能测试，甚至整个应用的功能测试后，再开始写单元测试。因为再写不同的功能时，可能还需要修改相关功能的模型代码，这时过早的单元测试反而是一种累赘。
发表回复