我对迄今为止的结果感到非常满意.重构真的很容易,我的测试帮助我发现了很多错误,甚至在我第一次运行我的软件之前.此外,我开发了更复杂的假冒和助手帮助我最大限度地减少测试代码.
不过,我不太喜欢的事实是,我经常发现自己不得不更新现有的单元测试来解释我对软件的重构.重构软件现在是快速和无痛的,但重构我的单元测试是相当无聊和乏味.事实上,维护单元测试的成本高于首先编写它们的成本.
我想知道我可能会做错事,还是测试开发成本与测试维护的关系是否正常.我已经尝试编写尽可能多的测试,以便这些覆盖我的用户故事,而不是系统地覆盖我的对象的界面,如this blog article所示.
此外,您是否还有如何编写TDD测试的其他提示,以便重构会尽可能少地进行测试？
编辑：正如Henning和tvanfosson所说的那样,编写和维护通常是最昂贵的设置部分.破碎的测试(在我的经验中)通常是重构域模型的结果,该模型与这些测试的设置部分不兼容.
在长时间遵循这些模式之后,我写了AutoFixture,这是一个封装了很多这些核心模式的开源库.
它作为一个Test Data Builder,但也可以连接起来作为一个自动模拟容器,并做许多其他奇怪和奇妙的事情.
它有助于维护,因为它提高了大量写作测试的抽象水平.测试成为更多的声明性,因为您可以声明您想要某种类型的实例,而不是明确地写出如何创建它.
想象一下,你有一个具有这个构造函数签名的类
public MyClass(Foo foo,Bar bar,Sgryt sgryt)
只要AutoFixture可以解析所有的构造函数参数,就可以简单地创建一个新的实例,如下所示：
var sut = fixture.CreateAnonymous<MyClass>();
主要好处是,如果您决定重构MyClass构造函数,则无需测试,因为AutoFixture会为您找出结果.
这只是一瞥AutoFixture可以做什么.它是一个独立的图书馆,因此它将与您选择的单元测试框架一起使用.
