我看到了TDD的好处,我正在努力学习如何绕过它.我也在阅读有关DDD的更多内容,并希望开始将它们应用到我的软件项目中.
我已经购买了一些"亲自动手"的编程书籍(通过"亲自动手",我的意思是那些用真正的解决方案而不是小片段来讨论真实世界的应用程序)我注意到他们通常开始定义"基础设施"以传统的代码优先方式使用应用程序层,而不是使用TDD; 这两本书都不遗余力地讨论TDD有多好以及案例研究将如何利用它.
例如,在其中一本书" ASP.NET 3.5社交网络"中,整个第二章开发了一个Logging包装类,一个Email包装类,Cache和Session包装类(及其相关的接口),所有这些都没有涉及单个单元测试.另一本书,.NET域驱动设计与C#:问题,设计,解决方案类似,并在触及"真实"代码之前创建基类和存储库框架代码优先.
我知道您应该测试域类的实际逻辑和功能.我曾经认为"不测试管道"代码只适用于您没有编写的代码(例如内置的.NET类),但我正在阅读的内容似乎表明/建议您只应测试代码这实际上与您的应用程序有关,而不是您编写的管道提供基础.
这是应用TDD的可接受方式吗?
学习TDD时,应用一切.然后,应用你需要的东西.
如果你从头开始编写管道,那么你应该围绕它进行测试.如果你只是使用一些接口和类来抽象你的linq2sql调用那么,不,我不一定会对它进行单元测试.
引用比我聪明的人:
我不是在谈论TDD.我认为这是一门值得追随的学科.我没有先写完所有测试.在代码之后编写它们中的一小部分会更方便.甚至有些代码我根本不写测试,因为它不值得.但那些是规则的例外.我写的绝大多数代码,我先写测试.
-uncle bob martin来自:http://www.infoq.com/news/2009/02/spolsky-vs-uncle-bob