在新项目中何时引入单元测试？

Question

在新项目中何时引入单元测试？

4

首先，让我说一下，没有单元测试的编码是非常疯狂的。没有单元测试，我就会一直担心不注意就会破坏某些东西。因此，我完全支持单元测试，并且我更喜欢使用TDD进行测试。

然而，我的问题是：在开始新项目时何时引入单元测试？按照TDD的精神，项目的第一行代码可能应该是一个单元测试。然而，无论我有多么喜欢TDD给我的那种模糊感觉，当你什么都没有的时候，我经常发现从一开始就进行单元测试很困难。通常情况下，我发现在看到项目将要走向何方时，不测试而编码更容易，“作弊”并引入测试。

人们对此有什么看法？在开始新项目时应该何时引入单元测试？

- stiank81

相关问题：https://dev59.com/THI-5IYBdhLWcg3wMFIf - Mark Seemann

12个回答

网页内容由stack overflow 提供, 点击上面的

可以查看英文原文，
原文链接

- Mawg says reinstate Monica · Answer 1

免责声明：我是一个老派、硬核的瀑布流开发者，不是TDD（我确实理解敏捷开发、交叉编程、TDD等，但不想引发宗教战争）。

你问什么时候“引入”单元测试，但没有定义“引入”的含义。按照我的理解，你的意思是“开始测试”。

让我们来看看老派的方法……一旦你已经审查并签署了系统文档，你就可以编写和审查系统/集成测试规范。一旦你已经审查并签署了详细设计文档，你就可以开始编写和审查单元测试规范。

没有详细设计文档？那就算了吧，你还没有准备好开始编码，更别提考虑单元测试了。

假设你已经同意了详细设计文档，其余的就是品味问题了。

你可以先编写测试用例，或者让其他人与你同时编写代码并行编写测试用例；你也可以在编码时进行测试，等等。

老派的做法是先编写代码，然后通过一些静态代码分析工具（如Splint、CppCheck等）运行它，然后才开始运行单元测试（这可能在编写代码之前就已经完成了）。

只是不要忘记黄金法则——如果需求、架构、设计没有被完全“完成”和“审查”，那么你正在建立一个基于沙子的房子——不要进行编码或单元测试。

但顺序是你的选择。什么对你、你的团队、你当前的项目最有效？并且ymmv。

- Matthew Flynn · Answer 2

创建必要的接口来进行测试。
编写测试。
编写代码以通过测试。
重复上述步骤。