TDD和小型团队短期项目的单元测试？

Question

TDD对于由多达4人的小团队完成的小型和短期项目来说是一个很好的方法吗？这真的是一项有利可图的工作吗？

单元测试怎么样？ TDD意味着单元测试，但相反。在项目开发生命周期中不时进行单元测试是否足够，直到合理的代码覆盖率？

Answer 1

答案是肯定的！并由于以下原因。 想象你自己下面的场景。您和您的项目团队已经创建了一个伟大的应用程序，并决定将其投入生产。过了一段时间，一个用户来找你说：嘿，我发现你的应用程序中有一个错误，你可以修复它吗？当然你会说是修正bug并且用户很高兴。只是过了一段时间，他回来说，很好，你解决了这个问题，但现在有一些工作已经不复存在了，你能修复它吗？

如果您使用过TDD并为应用程序进行过单元测试，那么情况就不会如此。这是因为您有针对整个应用程序进行的测试。解决了一个bug之后，您只需再次运行单元测试，看看您的“修复”是否会破坏应用程序中的其他任何内容。

这个答案更多的是针对单元测试的使用。以下是关于TDD本身。

什么TDD让你作为一个人做的是思考我要在下面的代码（对象，类，函数等）。另外我的代码的边缘是什么if/else语句我需要什么我需要检查。如果你是由你自己或由20人组成的项目团队，这并不重要。 TDD的事情是你的思维过程，而不是你项目中的其他人。

Answer 2

如果你正在UnitTesting采取TDD的唯一一小步。但你会从中受益更多。

只是一个例子：TDD定义您首先实施您的测试。这意味着你在开始实施之前想到你想达到的目标。这导致更好的代码。

Answer 3

对我来说，这并不归结为项目是小还是短。 TDD，正确地完成，是关于能够快速运行一组测试，提供充分的代码信心。还有很多关于TDD的文章都有助于推动项目的适当设计。

所以，你可能会认为TDD在小项目和短项目中是最好的，因为最终你只需编写代码就可以让测试通过，而不需要其他任何东西。因此，降低成本。然后，当您稍后进行更改时，还有对测试和代码充满信心的额外好处。

我会做的下一个小点是，许多项目开始小而短。这些临时解决方案有成为发展战略平台的方法（如果成功的话）。

Answer 4

TDD和单元测试不是彼此替代的。在每个项目中你都应该测试你的代码，这就是你进行单元测试和集成以及系统测试的地方。

TDD是一种发展模式。像瀑布和其他开发方法一样，TDD也是一种方法。在TDD中，您有一些基本要求，您可以编写单元测试以确保需求得到实施和运行。但是当你编写单元测试时，你会意识到为了达到主要要求，你需要实现更多的功能和类。所以在这种情况下的单元测试使其他需求更清晰。

假设您需要编写一个应用程序来打印运行应用程序的计算机的名称。首先你写一个单元测试：

[Test] 
public void ProducedMessage_IsCorrect() 
{ 
    AreEqual(BusinessLibrary.ProduceMessage(), System.Environment.MachineName); 
} 

然后你意识到你需要实现ProduceMessage函数。你可以很简单地实现它，以便单元测试通过。你写这样的方法：

public string ProduceMessage() 
{ 
    return "MyComputer"; 
} 

然后你运行测试，它通过。之后，您提交代码，团队的其他成员获取代码。当他们运行测试时，测试失败，因为您在代码中硬编码了计算机的名称。

因此，您的团队中一些明智的成员将代码更改为正确的形式，并继续前进。

这完全是关于选择具有TDD经验的开发人员。至少其中一些应该是我认为的有经验的TDD开发人员。

Answer 5

最近我读了Szymon Pobiega的好博客文章，标题为If you are not doing TDD…。我真的很希望看看这个。这是因为我对TDD持怀疑态度，并将其置于开发生命周期的良好习惯中，作为项目安全性的最终解决方案，除了项目的性质之外。我喜欢这个片段：

当你完全不知道 代码的形状时，TDD是最有用的。在这种情况下，您最好不要像代码 那样快速破解代码。而不是一次一小步，每次验证结果 。理想情况下，做一对。您所做的每一步都允许您 发现更多需要编写的测试。我喜欢在他的演讲中使用的比喻丹 ：这就像游泳与步行在 1.50米深池。你可以一直走路，确保每次你脚上的一只脚在地面上，或者你可以游泳时更有风险（与地面没有接触），但可以让你移动更快。 TDD就像走路一样。

他引用Dan North session from NDC 2012。