在我经历这个过程时,我觉得在应用程序完成后做测试会更容易,但是如果这样做,我将失去TDD的所有好处。
那么,有没有编写可维护的TDD代码的提示/技巧?我目前正在阅读Roy Osherove的The Art Of Unit Testing,还有其他资源可以帮助我吗?
谢谢
实践
学习撰写良好的单元测试需要一定时间。一个困难的项目(更像是多个项目)并不奇怪。
已经推荐的xUnit Test Patterns书籍很好,我听说你正在阅读的那本书也不错。
至于一般性建议,这取决于测试中出现了哪些问题。如果它们经常出错,它们可能不是单元测试,而更像是集成测试。如果设置困难,则SUT(被测试系统)可能显示出过于复杂,并需要进一步模块化。清单还可以继续。
我遵循的一些建议是遵循AAA规则。
安排,执行和断言。每个测试都应该遵循这个公式。这使得测试易读,并且在需要维护时易于维护。
设计仍然很重要
我实践TDD,在编写任何代码之前,我会拿起白板涂鸦。虽然TDD允许您的代码逐步发展,但一些前期设计总是有益的。然后你至少有一个起点,从这里你的代码可以由你编写的测试驱动。
如果我正在执行特定的困难任务,我会制作一个原型。忘记TDD,忘记最佳实践,只是批量处理一些代码。显然,这不是生产代码,但它提供了一个起点。从这个原型开始,我再考虑真正的系统以及我需要什么测试。
查看Google Testing Blog-这是在开始TDD时对我自己的转折点。 Misko的文章(和网站-尤其是关于可测试代码的指南)非常好,并且应该指引您朝着正确的方向。
"当需求开始改变,我开始进行重构时,我发现我花费的时间在重写/修复单元测试上比写代码的时间还要多,事实上多得多。"
那么?这是一个问题吗?
你的需求改变了。这意味着你的设计必须改变。这意味着你的测试也必须改变。
"我花费的时间在重写/修复单元测试上比写代码的时间还要多,事实上多得多。"
这意味着你做得很对。需求、设计和测试的影响都在测试中,而你的应用程序并不需要太多的更改。
这就是它应该工作的方式。
回家高高兴兴。你已经做好了工作。
你是否广泛使用接口、依赖注入和模拟?
我发现,设计接口并使用像ninject这样的DI框架注入这些接口的实现,可以更轻松地模拟应用程序的部分内容,以便正确地测试各个组件。
这样,就可以更轻松地在一个区域进行更改,而不会对其他区域产生太大影响,或者如果确实需要传播更改,则只需更新接口,并逐个处理每个不同的区域。
你使用的是好的集成开发环境吗?几年前,当我第一次接触单元测试时,我也问过自己同样的问题。那时,我使用的是Emacs
、find
和grep
的组合来进行重构。这很痛苦。
幸运的是,我的一个同事敲了我一下脑袋,并说服我尝试使用“现代工具”,在他的话中意味着Intellij IDEA。IDEA是我个人的首选,但Netbeans或Eclipse同样可以处理基本操作。这为我带来了难以言喻的生产力提升;特别是对于有大量测试的大型项目,效果更加显著。
一旦你选择了一个IDE,如果你仍然遇到问题,那么就该考虑DRY原则了。该原则旨在确保信息只保存在一个地方(常量、属性文件等),以便以后需要更改时最小化连锁反应。