unit-testing - 关于如何编写对重构友好的单元 TDD 测试的技巧

Question

我已经在 ASP.NET MVC 项目上工作了大约 8 个月。在大多数情况下，我一直在使用 TDD，只有在我编写了实际代码之后，单元测试才会覆盖某些方面。总的来说，该项目具有很好的测试覆盖率。

到目前为止，我对结果非常满意。重构确实要容易得多，我的测试甚至在我第一次运行我的软件之前就已经帮助我发现了很多错误。此外，我开发了更复杂的假货和助手来帮助我最小化测试代码。

然而，我真正不喜欢的是我经常发现自己不得不更新现有的单元测试来解释我对软件所做的重构。重构软件现在快速而轻松，但重构我的单元测试非常无聊和乏味。事实上，维护我的单元测试的成本高于首先编写它们的成本。

我想知道我是否可能做错了什么，或者测试开发成本与测试维护成本的这种关系是否正常。我已经尝试编写尽可能多的测试，以便这些测试涵盖我的用户故事，而不是像 this blog article 中建议的那样系统地涵盖我的对象界面。 .

另外，您是否有关于如何编写 TDD 测试以便重构中断尽可能少的测试的其他提示？

编辑:正如 Henning 和 tvanfosson 正确指出的那样，通常编写和维护成本最高的是设置部分。损坏的测试(根据我的经验)通常是重构域模型的结果，该模型与这些测试的设置部分不兼容。

Answer 1

这是一个众所周知的问题，可以通过根据最佳实践编写测试来解决。这些做法在优秀的 xUnit Test Patterns 中有所描述。 .本书描述了导致不可维护测试的测试气味，并提供了有关如何编写可维护单元测试的指导。

在遵循这些模式很长时间后，我写了 AutoFixture这是一个开源库，封装了许多这些核心模式。

它用作 Test Data Builder ，但也可以连接起来用作 Auto-Mocking 容器并做许多其他奇怪而奇妙的事情。

它在维护方面有很大帮助，因为它大大提高了编写测试的抽象级别。测试变得更多 声明式 因为你可以声明你想要一个特定类型的实例，而不是明确地写出它是如何创建的。

想象一下，你有一个带有这个构造函数签名的类

public MyClass(Foo foo, Bar bar, Sgryt sgryt)

只要 AutoFixture 可以解析所有构造函数参数，您就可以简单地创建一个新实例，如下所示:

var sut = fixture.CreateAnonymous<MyClass>();

主要的好处是，如果您决定重构 MyClass 构造函数，则不会中断测试，因为 AutoFixture 会为您解决。

这只是 AutoFixture 可以做什么的一瞥。它是一个独立的库，因此它将与您选择的单元测试框架一起使用。