我看到了TDD的好处,我正在努力学习如何绕过它.我也在阅读有关DDD的更多内容,并希望开始将它们应用到我的软件项目中.
我已经购买了一些"亲自动手"的编程书籍(通过"亲自动手",我的意思是那些用真正的解决方案而不是小片段来讨论真实世界的应用程序)我注意到他们通常开始定义"基础设施"以传统的代码优先方式使用应用程序层,而不是使用TDD; 这两本书都不遗余力地讨论TDD有多好以及案例研究将如何利用它.
例如,在其中一本书" ASP.NET 3.5社交网络"中,整个第二章开发了一个Logging包装类,一个Email包装类,Cache和Session包装类(及其相关的接口),所有这些都没有涉及单个单元测试.另一本书,.NET域驱动设计与C#:问题,设计,解决方案类似,并在触及"真实"代码之前创建基类和存储库框架代码优先.
我知道您应该测试域类的实际逻辑和功能.我曾经认为"不测试管道"代码只适用于您没有编写的代码(例如内置的.NET类),但我正在阅读的内容似乎表明/建议您只应测试代码这实际上与您的应用程序有关,而不是您编写的管道提供基础.
这是应用TDD的可接受方式吗？
如果你从头开始编写管道,那么你应该围绕它进行测试.如果你只是使用一些接口和类来抽象你的linq2sql调用那么,不,我不一定会对它进行单元测试.
引用比我聪明的人:
我不是在谈论TDD.我认为这是一门值得追随的学科.我没有先写完所有测试.在代码之后编写它们中的一小部分会更方便.甚至有些代码我根本不写测试,因为它不值得.但那些是规则的例外.我写的绝大多数代码,我先写测试.
-uncle bob martin来自:http://www.infoq.com/news/2009/02/spolsky-vs-uncle-bob
这可能取决于您计划如何构建项目的其他因素。
如果您遵循其他敏捷实践，例如小型迭代和交付，那么您一开始就不会有太多的架构或基础设施，因为在实施和交付敏捷实践时您没有时间进行太多开发。前几个功能。无论如何，当您并不真正知道代码需要什么时，为什么要花时间进行预先的大设计呢？
因此，您将首先测试并进行多次迭代来构建代码。测试覆盖率意味着您可以重构来改进您的设计，这（理论上）允许为应用程序随时出现正确的基础架构。Ron Jeffries 在这里解释得很好。如果没有测试，您可能会遇到需要停下来弄清楚结构应该是什么的情况，这将需要时间，而这些时间本可以更好地花在构建有用的功能上，并且您将不得不无论如何最后都要测试。
如果您在编写任何代码之前 100% 确定可以正确地制定设计，那么您可以选择这样做。不过，请确保在项目中留出足够的时间进行测试。我认为每个人都应该通过“传统”瀑布流程和深入编码来构建至少一项重要的工作，以便获得一些将敏捷实践融入上下文的经验。否则，你可能会面临只知道“什么”而不知道“为什么”的风险，而这会让课程变得更难学习。