C# 通过TDD创建映射函数：编写测试花费的时间太多？

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

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

---

例如，假设上面有十几个属性要映射。在TDD环境中，在编写任何映射之前，我可能会编写一个测试。类似于

maptoomapsbeveragetofooyuk（）

。测试失败，导致我编写代码使其通过。我对要映射的每个属性重复此操作。问题是：这种先测试后开发的做法是否太过分了？我个人不这么认为，因为我希望有一整套测试告诉我代码的具体功能，但我想听听社区的想法

也许这就是它诞生的原因。

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

---

如果您曾经编写过一个有副作用的属性（我怀疑您会），那么您可以向它添加一个单元测试。正如DuffyMo指出的那样，如果功能测试涵盖了您的属性，那么就不需要进行单元测试，因为除了简单的get/set之外，没有使用单元测试定义的功能规范。

在本例中，我将编写一个测试，一次测试所有简单的属性。这不是做事情的标准方法，但最终，对单个平凡属性的测试可能会被重构为对所有属性的单个测试。由于属性很琐碎，我建议从您结束的测试开始。

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

Po TAY to，Po TAH to。两者之间的界限不必如此明确。FitNesse似乎是将这些东西具体化的一个很好的方法。相关：你试过AutoMapper吗？--在某些情况下，您可以使用它来避免编写映射代码，另外它还具有运行时验证功能，非常适合编写快速测试。这看起来非常有趣。我们说话的时候我正在检查。谢谢你的链接。是的，我同意。有时我只是简单地让自己只编写回归测试（即，测试一个字段只有在被发现意外省略后才被映射）。