你应该在多大程度上应用TDD？

Question

我看到了TDD的好处，我正在努力学习如何绕过它。我也在阅读有关DDD的更多信息，并希望开始将它们应用到我的软件项目中。

我已经购买了一些“动手”编程书籍（通过“亲自动手”我的意思是那些用真实解决方案而不是小片段来讨论真实世界的应用程序）我注意到他们通常会开始定义应用程序的“基础结构”层以传统的代码优先方式，而不是使用TDD;这两本书都不遗余力地讨论TDD的优秀程度以及案例研究将如何利用它。

例如，在其中一本书 ASP.NET 3.5社交网络中，整个第二章开发了一个Logging包装类，一个Email包装类，Cache和Session包装类（及其相关的接口） ）所有没有触及单个单元测试。另一本书， .NET域驱动设计与C＃：问题，设计，解决方案类似，并在触及“真实”代码之前创建基类和存储库框架代码。

我知道您应该测试域类的实际逻辑和功能。我曾经认为“不测试管道”代码只适用于您没有编写的代码（例如内置的.NET类），但我正在阅读的内容似乎表明/建议您只应该测试代码这实际上与您的应用程序有关，而不是您编写的管道提供基础。

这是应用TDD的可接受方式吗？

Answer 1

学习TDD时，应用一切。然后，应用你需要的东西。

Answer 2

如果你是从头开始编写管道，那么你应该对它进行测试。如果你只是使用一些接口和类来抽象你的linq2sql调用那么，不，我不一定会对它进行单元测试。

引用比我聪明的人：

  

我不是在谈论TDD。一世   认为这是一门值得纪律的   以下。我不写所有测试   第一。其中一些是少数   写后简单方便   代码。甚至还有一些代码我   根本不写测试，因为   这不值得。但那些是   规则的例外情况。茫茫   我写的大部分代码都是我写的   先测试一下。

     

-uncle bob martin via：http://www.infoq.com/news/2009/02/spolsky-vs-uncle-bob

Answer 3

这可能取决于您计划如何构建项目的其他因素。

如果您正在遵循其他敏捷实践，例如小型迭代和交付，那么您一开始就没有太多的架构或基础架构，因为在实施过程中您将没有足够的时间进行开发并提供前几个功能。无论如何，当你真的不知道代码需要什么时，为什么要花时间在Big Design Up Front上呢？

因此，您将首先在多次迭代中构建代码。测试覆盖意味着您可以重构以改进您的设计，从理论上讲，它可以准确地为应用程序提供正确的基础架构，因为它可以随时存在。 Ron Jeffries explains it well here。如果没有测试，你可能会遇到需要停下来并找出结构应该是什么的点，这需要花费时间才能更好地用于构建有用的功能，并且你将不得不无论如何都要在最后测试。

如果你100％肯定你可以在编写任何代码之前正确地绘制出设计，那么你可以选择这样做。但是，确保在项目中留出足够的时间进行测试。我认为每个人都应该通过“传统的”瀑布流程以及潜入和编码来构建至少一项重要的工作，以便获得一些将敏捷实践置于上下文中的经验。否则，你有可能在不知道“为什么”的情况下知道“什么”，这使得课程更难学习。

Answer 4

如果您测试一些代码，而不测试其他代码，哪些代码会有错误？

提示：这是未经测试的代码。

Answer 5

我不是这里的专家。

但如果您正在开发管道组件，则应对其进行测试 如果我理解正确，使用TDD，代码写入接口＆amp;在没有管道组件的情况下，人们使用Mock对象。

Answer 6

我在another question中花了一些时间。基本上，使用TDD和模拟以及所有这些东西的关键是要增强信心。

Answer 7

TDD应该应用于您开发的任何代码。使用TDD时，您无需测试所有内容 - 即目标不是100％覆盖 - 但覆盖率应该高于您开发的代码。例如，您不需要在C＃中测试自动gettor / settors - 您可以相信该语言将在那里完成它的工作。但是，如果有疑问，请先写下测试。

Answer 8

通过各种方式编写代码优先获得平台体验 - 只要勇敢，一旦确定可以解决该平台上的大多数任务就扔掉它。我刚刚开始使用一个小型Java程序 现在我已经获得了一些经验，我可以看到我必须做什么才能获得非常高的线路覆盖率，因为我开始以测试优先的方式编写它，甚至是大部分的管道。