我最近使用TDD完成了一个项目,我发现这个过程有点像噩梦.我喜欢先编写测试并观察我的代码增长但是一旦需求开始变化并且我开始进行重构,我发现我花了更多的时间重写/修复单元测试而不是编写代码,事实上更多的时间.
我觉得在我完成这个过程的过程中,在应用程序完成后进行测试要容易得多,但如果我这样做,我会失去TDD的所有好处.
那么编写可维护的TDD代码有什么命中/提示吗？我现在正在阅读Roy Osherove的The Unit Of Unit Testing,还有其他资源可以帮助我吗？
谢谢
Fin*_*las 17
实践
学习如何编写体面的单元测试需要一段时间.一个困难的项目(更像是项目)并不奇怪.
推荐的xUnit测试模式书很好,我听说你正在阅读的这本书很好.
至于一般建议,它取决于你的测试很难.如果他们经常破坏,他们可能不是单元测试,更多的是集成测试.如果它们难以设置,SUT(被测系统)可能会显示过于复杂的迹象,需要进一步模块化.名单还在继续.
我所遵循的一些建议是遵循AAA规则.
安排,行动和断言.每项测试都应遵循此公式.这使得测试可读,并且在它们确实破坏时易于维护.
设计仍然很重要
我练习TDD,但在编写任何代码之前,我抓住了白板并随意涂鸦.虽然TDD允许您的代码发展,但一些预先设计始终是一个好处.那么你至少有一个起点,从这里你的代码可以由你编写的测试驱动.
如果我正在执行一项特殊的艰巨任务,我会制作一个原型.忘记TDD,忘记最佳实践,只是抨击一些代码.显然这不是生产代码,但它提供了一个起点.从这个原型我然后考虑实际的系统,以及我需要的测试.
查看Google测试博客 - 这是我开始使用TDD时的转折点.Misko的文章(以及网站 - 特别是可测试代码指南)非常出色,应该指向正确的方向.
"一旦需求开始变化,我开始进行重构,我发现我花了更多时间重写/修复单元测试"
所以？这怎么回事？
您的要求已更改.这意味着你的设计必须改变.这意味着你的测试必须改变.
"我花了更多时间重写/修复单元测试,而不是编写代码,事实上更多时间."
这意味着你做得对.要求,设计和测试影响都在测试中,您的应用程序不需要太多更改.
这就是它的工作方式.
回家快乐.你已经完成了这项工作.
我是单元测试的忠实粉丝,但在我最近的项目中遇到过TDD(或基本单元测试)的问题.在进行实施后审核后,我发现我们(我和团队的其他成员)在实施/理解TDD和单元测试时面临两个主要问题.
第一个问题是我们面临的是我们并不总是将我们的测试视为一等公民.我知道这听起来好像我们反对TDD的哲学,但我们的问题是在我们完成了大部分初始设计并且急于进行实时更改之后出现的.不幸的是,由于时间限制,项目的后期部分变得匆忙,我们陷入了编写代码后编写测试的陷阱.当压力安装的工作代码被检查到源控制而不检查单元测试是否仍然通过.不可否认,这个问题与TDD或单元测试无关,而是紧迫的截止日期,平均团队沟通和糟糕的领导(我会在这里责怪自己)的结果.
在深入研究失败的单元测试时,我们发现我们测试的太多,特别是考虑到我们的时间限制.我们使用TDD并为整个代码库编写测试,而不是使用TDD并将测试重点放在高回报的代码上.这使得我们的单元测试比例比我们维持的要高得多.我们(最终)决定只使用TDD并为可能发生变化的业务功能编写测试.这减少了我们维持大量测试的需要,这些测试在很大程度上很少(或从未)改变.相反,我们的努力得到了更好的关注,并为我们真正关心的应用程序部分提供了更全面的测试套件.
希望可以从我的经验中学习并继续开发TDD,或者至少仍然为您的代码开发单元测试.就个人而言,我发现以下链接对于帮助我理解选择性单元测试等概念非常有用.
| 归档时间： |
|
| 查看次数： |
1388 次 |
| 最近记录： |