Adr*_*ore 13 tdd refactoring unit-testing
我已经在ASP.NET MVC项目上工作了大约8个月了.在大多数情况下,我一直在使用TDD,只有在我编写实际代码之后才能通过单元测试来涵盖某些方面.总的来说,该项目的测试覆盖率非常高.
到目前为止,我对结果非常满意.重构真的更容易,我的测试帮助我在第一次运行我的软件之前发现了很多错误.此外,我开发了更复杂的假货和帮手,以帮助我最小化测试代码.
但是,我不喜欢的事实是,我经常发现自己必须更新现有的单元测试,以解释我对软件所做的重构.重构软件现在快速而轻松,但重构我的单元测试非常乏味和乏味.实际上,维护我的单元测试的成本高于首先编写它们的成本.
我想知道我是否可能做错了,或者测试开发与测试维护成本的关系是否正常.我已经尝试过编写尽可能多的测试,以便这些测试覆盖我的用户故事,而不是像本博客文章中所建议的那样系统地覆盖我的对象界面.
另外,您是否有关于如何编写TDD测试的进一步提示,以便重构尽可能少地进行测试？
编辑:正如Henning和tvanfosson正确评论的那样,通常设置部分的编写和维护成本最高.破坏的测试(根据我的经验)通常是对域模型进行重构的结果,这些重构与这些测试的设置部分不兼容.
这是一个众所周知的问题,可以通过根据最佳实践编写测试来解决.优秀的xUnit测试模式中描述了这些实践.本书描述了导致无法测试的测试气味,并提供了如何编写可维护单元测试的指导.
在长时间跟踪这些模式之后,我编写了AutoFixture,它是一个开源库,封装了很多这些核心模式.
它可以作为测试数据生成器使用,但也可以连接起来作为Auto-Mocking容器,并做许多其他奇怪和奇妙的事情.
它在维护方面有很大帮助,因为它提高了编写测试的抽象级别.测试变得更具声明性,因为您可以声明您想要某种类型的实例,而不是明确地写出它是如何创建的.
想象一下,你有一个带有这个构造函数签名的类
public MyClass(Foo foo, Bar bar, Sgryt sgryt)
只要AutoFixture可以解析所有构造函数参数,您只需创建一个这样的新实例:
var sut = fixture.CreateAnonymous<MyClass>();
主要的好处是,如果你决定重构MyClass构造函数,没有测试会中断,因为AutoFixture会为你解决问题.
这只是AutoFixture可以做的一瞥.它是一个独立的库,因此它可以与您选择的单元测试框架一起使用.
| 归档时间： |
|
| 查看次数： |
1381 次 |
| 最近记录： |