TDD 和单元测试，适用于小型团队的短期项目

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

因此，您可能会争辩说TDD最适合小型和短期项目，因为您最终只编写了使测试通过所需的代码，而没有其他内容。 因此，降低成本。 然后，还有一个额外的好处，即在以后进行更改时对测试和代码充满信心。

我要说的下一个小点是，很多项目都是从小而短的开始的。 这些临时解决方案有办法成为发展战略平台(如果成功的话(。

最近我读了Szymon Pobiega的一篇不错的博客文章，标题为"如果你不做TDD"。我真的很鼓励看看这个。这是因为我对TDD有点怀疑，并将其置于开发生命周期的良好习惯中，除了项目的性质之外，作为项目安全的最终解决方案。我喜欢这个片段：

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

他引用了 NDC 2012 中的 Dan North 会议。

答案是肯定的！原因如下。想象一下下面的场景。您和您的项目团队已经创建了一个出色的应用程序，并决定将其投入生产。过了一会儿，一个用户来找你说：嘿伙计们，我在你的应用程序中发现了一个错误，你能修复它吗？当然，您说是修复错误，用户很高兴。过了一会儿，他才回来说，很高兴你解决了问题，但现在确实有效的东西不再有效了，你能修复它吗？

如果您使用了 TDD 并为应用程序进行了单元测试，则方案不会是这样的。这是因为您已经为整个应用程序进行了测试。解决错误后，您只需再次运行单元测试，以查看您的"修复"是否破坏了应用程序中的任何其他内容。

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

TDD让你作为一个个体做的是思考我将在下面(对象，类，函数等(中编码什么。还有我的代码的边缘是什么，我需要 if/else 语句我需要检查什么。如果您独自一人或在 20 人的项目团队中，这并不重要。TDD的问题是你的思考过程，而不是项目中的其他人。

如果你正在做单元测试，那么采用TDD只是一小步。但你会从中受益更多。

仅举一个例子：TDD 定义您首先实现测试。这意味着您在开始实施之前要考虑要实现的目标。这会导致更好的代码。

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

然而，TDD是一种开发模式。像瀑布和其他开发方法一样，TDD也是一种方法。在TDD中，您有一些基本要求，并且编写单元测试以确保这些要求已实现并正常工作。但是当你在编写单元测试时，你意识到为了实现主要需求，你需要实现更多的函数和类。因此，此上下文中的单元测试使其他要求更加清晰。

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

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

然后你意识到你需要实现生产消息函数。您可以尽可能简单地实现它，以便单元测试通过。你像这样编写方法：

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

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

因此，您

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

这一切都与选择具有TDD经验的开发人员有关。我认为他们中的一些人至少应该是经验丰富的TDD开发人员。