Question

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

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

比如说，有大约十几个属性要映射到上面。在TDD环境中，在编写任何映射之前，我可能会编写一个测试。像MapToFooMapsBeverageToFooYuk()这样的东西。测试失败，导致我编写代码以使其通过。我为每个要映射的属性重复此操作。问题是：这是否将测试优先发展到了太远？我个人并不这么认为，因为我宁愿进行一整套测试，告诉我代码究竟做了什么，但我想听听社区的想法。

Answer 1

甚至叔叔鲍勃·马丁，TDD的坚定捍卫者以及TDD的所有东西，都表示你不必为每个琐碎的属性编写单元测试（一个简单的属性被定义为一个只获取并设置一个成员变量的属性）。

如果您曾经写过一个有副作用的属性（我怀疑你会这样做），然后你可以添加一个单元测试。正如DuffyMo所指出的，如果您的属性被功能测试所覆盖，则不需要进行单元测试，因为您没有使用单元测试定义的规范功能，除了琐碎的获取/设置。

Answer 2

也许这就是FitNesse诞生的目的。

Answer 3

在这个例子中，我写了一个测试，一次测试所有琐碎的属性。这不是标准的做事方式，但最终，对于所有属性的单个测试，可能会对单个平凡属性的测试进行重构。由于属性是微不足道的，我建议从你已经结束的测试开始。

Answer 4

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

通过TDD创建映射函数：花费太多时间进行写作测试？

4 个答案: