TDD /单元测试 - 确定打破现有测试

在TDD的re-factor阶段可以将多个现有测试分为一次。例如，要更改类的构造函数并且必须修改使用该类的测试。TDD /单元测试 - 确定打破现有测试

测试声明测试代码的behaviour，但测试arrange/act的实现实际上是测试代码本身。

我想避免多个测试打破单元测试应该尽可能干，这意味着如果构造函数更改（如果可能）应该需要单个更新。

理想情况下，您应该尝试将测试的设置代码保存在一个常见的位置，以便所有测试都可以请求某个类型的实例从“权威来源”进行测试。因此，第一步是重构测试以从共享助手方法获取实例，而不是自行调用new。

然后，您可以重构构造函数以获取更多参数。现在，你有一个地方可以修复。

我经常打电话给这个帮手TestDataFactory。它知道一些关于对象模型的知识，所以你可以问它一个Foo的实例，它会在大多数字段中返回一个包含大量有用测试数据的实例。

2014-09-03 13:36:55

尽管我大多数人都同意@Aaron，但我不会一次打破多个测试。最重要的是你可以彻底地测试你的代码。事实上，建议我也有一个地方来改变代码中断，但有时会增加不必要的复杂性。 – 2014-09-03 13:55:31

这种情况一直发生在我身上，带有构造函数或任何在多个地方被调用的东西。我不认为这是一个大问题，我通常只是纠正任何意外失败的测试，然后继续进行我的测试。

有些人已经考虑过避免这种情况的技术，在不希望在非编译状态下花费数小时的情况下运行重构。例如，见Joshua Kerievsky创造的"Limited Red"的概念。

2014-09-04 12:32:24 guillaume31

由于@Arron已经表明，第一步是重新提前重新分解代码，并使用您将要测试的方法实例化对象以实例化工厂方法。

例如

var sut = CreateSUT(); 
var result = sut.MethodUderTest(); 
Assert.IsTrue(result);

对于更复杂的对象，你可能要考虑使用类似的测试数据生成器模式的模式。这blog很好地描述了模式。

2014-09-04 20:18:31 Andrew

我对上面提到的大部分内容都赞不绝口，但我通常会做一些改变。我不喜欢打破我目前正在研究的范围之外的测试。然而，我也不想限制基于一些不合理的“代码行政恐惧”（我认为像这样的精神问题会产生更大的质量问题）来重构我的重构。

所以我通常做的是，我添加新的代码与新的行为，保持旧的一小段时间（不赞成它），只是足够长的新功能稳定。然后，我在同一时间内全部处理所有其他测试，确保您只修复此问题。

在C＃中（作为例子）带有默认值的可选参数可以真正帮助我，但除此之外，我只是重载或创建新的ctor/methods。

这样做会让我更专注于手头的任务（测试），但更重要的是，它还使我在重构时保持无情。这种重构感觉更自然，破坏性更小。

我真的不适用于单元测试的一个主体是DRY。我不会推荐任何人将这种想法带到测试世界。 DRY倾向于创建难以遵循的测试用例。我宁愿在测试中使用很多代码，但很容易遵循，而不是DRY。

2014-09-17 04:16:29 gurun

回答