我已经在一个ASP.NET MVC项目上工作了大约8个月。大部分时间我都在使用TDD,但有些方面的单元测试只是在我编写实际代码之后才覆盖了它们。总体而言,该项目的测试覆盖率相当好。
到目前为止,我对结果感到非常满意。重构确实更容易了,我的测试也帮助我在第一次运行软件之前发现了很多错误。此外,我还开发了更复杂的伪造对象和辅助程序来帮助我最小化测试代码。
然而,我真正不喜欢的是,我经常发现自己不得不更新现有的单元测试以适应我对软件所做的重构。重构软件现在很快,也很容易,但重构我的单元测试则相当无聊和繁琐。事实上,维护我的单元测试的成本比起一开始编写它们来说更高。
我想知道是否我做错了什么?或者测试开发成本与测试维护成本的这种关系是否正常?我已经尝试编写尽可能多的测试用例,以便这些测试用例覆盖我的用户故事,而不是像这篇博客文章中建议的那样系统地覆盖我的对象接口。
此外,您有什么进一步的提示,可以帮助我编写TDD测试用例,使重构对测试的破坏尽可能少?
编辑:正如Henning和tvanfosson正确指出的那样,通常是设置部分最难编写和维护的。破碎的测试通常是由于对这些测试的设置部分不兼容的域模型重构导致的(根据我的经验)。