4

我是 TDD 的狂热爱好者，并且总是努力在编写生产代码之前编写测试，以确保我正在编写的代码的正确行为。然而，偶尔会有几个问题，是否为某些类型的方法编写大量测试是谨慎的。这似乎在编写映射器类时最常出现。

public class FooBarMapper
{
    public Foo MapToFoo(Bar bar)
    {
        return new Foo
        {
            Id = bar.Id,
            Name = bar.Name,
            FooYuk = bar.Beverage,
            /* ... */
        };
    }
}

例如，上面有大约十几个属性要映射到上面。在 TDD 环境中，在编写任何映射之前，我可能会编写一个测试。类似的东西MapToFooMapsBeverageToFooYuk()。测试失败，导致我编写代码使其通过。我对每个要映射的属性重复此操作。问题是：这是否将测试优先的开发走得太远了？我个人不这么认为，因为我宁愿有一整套测试告诉我代码的确切作用，但我想听听社区的想法。

4

4 回答 4

3

即使是 TDD 和所有 TDD 的坚定捍卫者 Bob Martin 叔叔也表示，您不必为每个琐碎的属性（琐碎的属性被定义为只获取和设置成员变量的属性）编写单元测试。

如果您曾经编写过具有副作用的属性（我怀疑您会这样做），那么您可以向其添加单元测试。正如 DuffyMo 指出的那样，如果您的属性被功能测试覆盖，则不需要单元测试，因为除了琐碎的 get/set 之外，没有您使用单元测试定义的功能规范。

于 2010-01-16T18:15:52.583 回答
0

映射前三个属性后，我会看到重复项并通过迭代属性并使用反射分配它们来替换它。这只需要几个测试：0 个属性，1 个属性，5 个属性，目标对象没有预期的属性，源对象没有预期的属性。现在，我可以在所有应用程序的其他任何地方重用这个通用映射引擎，而且我不必每次使用它时都检查它。

于 2010-01-20T08:14:01.007 回答
0

在这种情况下，我会编写一个测试，一次测试所有的琐碎属性。这不是标准的做事方式，但最终，对个别琐碎属性的测试可能会被重构为对所有属性的单一测试。由于属性是微不足道的，我建议从你已经结束的测试开始。

于 2010-01-16T18:42:04.833 回答
0

也许这就是FitNesse的诞生。

于 2010-01-16T17:57:22.530 回答