TDD在一个大项目中：你如何开始？

Question

简单的问题。让我们戴上我们的工程师/项目经理帽子一秒钟：

你有一个大项目，你将有几个不同的开发人员在不同的部分工作。您有一个可靠的功能规范，并准备开始计算您的实现。您想练习测试驱动开发。假设你将获得合理但不是无限的时间和金钱。

如何开始准备其他开发人员实施的模块？你开始编写接口还是开始编写测试？你混合n'匹配吗？

如果你有一支经验丰富的编码员团队，你会如何改变你的答案？一群经验不足的人？您的编码环境会改变您的决定吗？

Answer 1

严格来说 - 如果您正在进行TDD（不仅仅是单元测试），那么在编写单元测试实际测试的功能之前，先从测试开始。 您编写的所有功能都需要编写测试来验证您要编写的代码。

开发人员本身就是编写单元测试的人 - 功能/验收测试是一个单独的问题，可以在工作开始之前（部分）编写。

如果团队没有单元测试的经验，他们应该开始实现功能，然后在每个小类/小功能完成后立即编写单元测试

单元测试（以及TDD因此）不测试系统模块 - 它们要在更细粒度的级别进行测试 - 即函数和类执行开发人员期望它们的操作。 更高级别的测试超出了TDD的范围，并进入其他类型的测试

Answer 2

如果你有一个好的功能规范，我会拆分工作......并开始研究测试用例。

一旦你完成了测试用例，开发人员就可以开始对他们的模块和测试进行编码了。

......并且该方法不会因不同的开发人员或编码环境而改变。

Answer 3

没有在这里搜索和相当新，我猜这里有很多讨论，但我还是要给出答案。

首先，我会问一个'大型'项目你的意思？我看到有些人将项目标记为几个月，涉及4或5名程序员作为“大项目”。对于其他人来说，“大项目”意味着多年的持续时间和30或40个开发者。考虑到你提到'几个开发者'，我会假设它在中间的某个地方。为了安全起见，我们假设持续时间为半年到一年，持续时间为5-10个。

正如其他人所说，如果你正在进行TDD，你首先要从测试开始，而不是进行大量的设计工作。设计很紧急。然而，在实践中，我认为TDD方法（我认为有价值但不是必要的）之间存在平衡，并且只是确保您拥有良好的单元测试覆盖率，在我看来 是必不可少的。

如果你自己是一名程序员而且你有TDD经验，我建议你应该练习你将要讲的内容。而不是试图在抽象层面设计整个系统，定义接口等，选择系统的核心部分。确保做最简单的事情，得到一个绿色条，重构，添加另一个测试，等等。

在与多个开发人员合作的项目中使用TDD的最大障碍是缺乏该方法的经验。给你的程序员一个具体的例子（即使它只是一小部分功能）真正向他们展示了如何做到这一点正确的方式，在他们进入项目时与人配对，定期审查人们的单元测试，并确保它继续成为你正在做的事情的最前沿的主题，而不仅仅是事后的想法。如果您正在使用Scrum，请将其作为任何任务/故事的“完成”定义的一部分。

我还会花一些时间设置像EMMA或Cobertura（Cobertura的忠实粉丝）这样的东西，所以你有一些很难用来评估人们测试的指标。有效的测试，但它们是一个数据点。如果您有20％的测试覆盖率，那么您可以非常确定人们不会编写应该进行的测试。相反，仅仅因为你有90％的测试覆盖率并不能确保测试是好的，这就是配对和评论之类的事情。

所以，简单的答案是：给你的家伙一个例子，专注于配对/评论，并把一些东西放在适当的位置，就像代码覆盖工具一样，以帮助团队保持诚实。

Answer 4

TDD并非完全您正在寻找的东西。 TDD发生在项目的开始并推动开发，因此测试驱动开发。

您可能正在寻找的是测试编写策略。从以后在许多大型项目中实施测试，这里有一些提示：

• 从小处开始。不要试图在整个项目上获得100％的覆盖率，选择一个类或一组函数并从那里开始。

• 冲动将从您最小/最简单的类/函数开始，只是为了获得一些快速获胜并且一个文件的代码覆盖率为100％。不。

• 相反，当您获得错误报告并修复它们时，请编写测试以支持自己。编写测试来演示错误，修复错误，运行测试而不会看到错误，这是一项非常有效的练习。

• 当您收到新功能请求时，请编写测试以支持自己。这与修复错误的效果相同。

• 一旦编写了一些测试，就连续运行它们。如果他们都被打破和/或没有被运行，那就没有必要进行测试。

没错，你最终没有达到100％的代码覆盖率，但是你可以稳定而且经常地应用越来越多的测试，在十几个bug之后，你会有很多有用的测试。更重要的是，您将获得越来越多的测试是系统中“最差”或最有问题的领域。我们现在正在使用web2project执行此操作：http://caseysoftware.com/blog/unit-testing-strategy-web2project。

Answer 5

在传统开发（非TDD）中，在具有功能规范和编写第一行代码之间，涉及许多设计。你仍然需要经历这个过程，这绝对取决于团队的技能水平。 TDD中唯一不同的是在编写代码之前编写测试用例。如果不知道涉及哪些类/接口，你显然无法编写测试。