大型项目中的TDD :如何开始？

Question

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

你有一个很大的项目，你会有几个不同的开发人员在不同的部分工作。你已经有了一个可靠的功能规范，并且准备好开始弄清楚你的实现了。你想练习测试驱动开发。假设你会得到合理的，但不是无限的时间和金钱。

您如何开始准备模块以供其他开发人员实现？您是开始编写接口还是开始编写测试？你会混合n‘match吗？

如果你有一个经验丰富的程序员团队，你会如何改变你的答案？一群经验较少的人？你的编码环境会改变你的决定吗？

Answer 1

严格地说-如果你正在做TDD (不仅仅是单元测试)，那么在编写单元测试实际测试的函数之前，你首先要开始测试。您编写的所有功能都需要编写测试来验证您将要编写的代码。

开发人员自己将是编写单元测试的人-功能/验收测试是一个单独的问题，可以在开始工作之前(部分)编写。

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

单元测试(以及作为结果的TDD )不是测试系统的模块-它们是在更细粒度的级别上测试-也就是说，函数和类做开发人员期望它们做的事情。更高级别的测试超出了TDD的范围，而进入了其他类型的测试

Answer 2

如果你有一个很好的功能规范，我会把work...and分成两部分来处理测试用例。

一旦你完成了测试用例，开发人员就可以开始编写他们的模块和相应的测试。

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

Answer 3

这里没有搜索，也不是很新，我猜围绕这个问题已经有很多讨论了，但不管怎样，让我给出一个答案。

首先，我想问一下你所说的“大型”项目是什么意思？我曾见过一些人将一个耗时几个月、涉及4到5个程序员的项目称为“大项目”。对另一些人来说，“大项目”意味着多年的持续时间和30或40个开发人员。考虑到你提到的“几个开发人员”，我假设它在中间的某个地方。为了安全起见，让我们假设它的持续时间是半年到一年，有5-10个开发者。

正如其他人所说，如果你在做TDD，你应该先从测试开始，而不是很多设计工作。设计是紧急的。然而，在实践中，我认为TDD方法(我认为这是有价值的，但不是必要的)和简单地确保你有良好的单元测试覆盖率之间是平衡的，这在我看来是至关重要的。

如果你自己是一名程序员，并且你有TDD的经验，我建议你应该实践你将要宣扬的东西。选择系统的核心部分，而不是试图在抽象级别上设计整个系统，定义接口等。确保尽可能做最简单的事情，获得一个绿色条，重构，添加另一个测试，等等。

在有多个开发人员的项目中使用TDD的最大障碍是缺乏方法方面的经验。给你的程序员一个具体的例子(即使是很小的功能)，向他们展示如何以正确的方式做这件事，在他们进入项目时与人们配对，定期审查人们的单元测试，并确保它仍然是你正在做的事情的前沿主题，而不仅仅是事后才想到的主题。如果你正在做Scrum，那就让它成为你对任何任务/故事的“完成”定义的一部分。

我还会花一些时间设置像EMMA或Cobertura (Cobertura的铁杆粉丝)这样的东西，这样你就有了一些硬性的指标来评估人们的测试。你的测试是有效的，但它们是一个数据点。如果你有20%的测试覆盖率，你可以非常确定人们没有写他们应该写的测试。相反，仅仅因为你有90%的测试覆盖率并不能确保测试是好的，这就是像配对和审查这样的事情的原因。

所以，简单的答案是:给你的人一个例子，专注于配对/评审，并将一些东西放在适当的位置，比如代码覆盖工具，以帮助保持团队的诚实。