通过 TDD 创建映射函数：编写测试花费了太多时间？
我是 TDD 的狂热爱好者，并且总是努力在编写生产代码之前编写测试，以确保我正在编写的代码行为正确。然而，有时，一些人会质疑为某些类型的方法编写大量测试是否明智。这似乎在编写映射器类时最常出现。
public class FooBarMapper
{
public Foo MapToFoo(Bar bar)
{
return new Foo
{
Id = bar.Id,
Name = bar.Name,
FooYuk = bar.Beverage,
/* ... */
};
}
}
例如，上面有大约十几个属性要映射。在 TDD 环境中，在编写任何映射之前，我可能会编写一个测试。类似MapToFooMapsBeverageToFooYuk()。测试失败，导致我编写代码使其通过。我对要映射的每个属性重复此操作。问题是：这种测试优先开发是否太过分了？我个人不这么认为，因为我宁愿有一套完整的测试来告诉我代码到底做了什么，但我想听听社区的想法。
I'm a big TDD enthusiast, and always strive to write tests before writing production code to ensure correct behavior of the code that I'm writing. Occasionally, however, several question if it is prudent to write a large body of tests for certain kinds of methods. This seems to come up most often when writing a mapper class.
public class FooBarMapper
{
public Foo MapToFoo(Bar bar)
{
return new Foo
{
Id = bar.Id,
Name = bar.Name,
FooYuk = bar.Beverage,
/* ... */
};
}
}
Say for example that there are about a dozen properties to map to above. In a TDD environment, before writing any of the mappings, I'd probably write a test. Something like MapToFooMapsBeverageToFooYuk(). The test fails, leading me to write the code to make it pass. I repeat this for each property to map. The question is: Is this taking test-first development too far? I personally don't think so, as I'd rather have a full suite of tests telling me exactly what the code does, but I'd like to hear what the community thinks.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
即使是 TDD 和所有 TDD 的坚定捍卫者 Bob Martin 叔叔也表示，您不必为每个琐碎的属性编写单元测试（琐碎的属性被定义为仅获取和设置成员变量的属性）。
如果您曾经编写过具有副作用的属性（我怀疑您会这样做），那么您可以向其添加单元测试。正如 DuffyMo 指出的那样，如果功能测试涵盖了您的属性，则应该不需要单元测试，因为除了简单的 get 之外，您在单元测试中定义的功能没有规范 /放。
Even Uncle Bob Martin, a staunch defender of TDD and all things TDD, says that you don't have to write unit tests for every trivial property (a trivial property being defined as a property that just gets and sets a member variable).
If you ever write a property that has side-effects (which I doubt you will), then you can add a unit test to it. As DuffyMo points out, if your properties are covered by functional testing, there should be no need for unit tests, since there is no specification of functionality you are defining with the unit test, other than the trivial get/set.
也许这就是 FitNesse 诞生的原因。
Maybe this is what FitNesse was born for.
在这种情况下，我将编写一个测试来一次测试所有琐碎的属性。这并不是一种标准的做事方式，但最终，对单个琐碎属性的测试可能会被重构为对所有属性的单个测试。由于这些属性很琐碎，我建议从您已经结束的测试开始。
In this instance, I'd write a single test that tests all the trivial properties at once. It's not quite the standard way to do things, but eventually, the tests for individual trivial properties would probably be refactored into a single test for all properties. Since the properties are trivial, I propose starting off with the test you'd have ended with.
映射前三个属性后，我会看到重复项，并通过迭代属性并使用反射分配它们来替换它。只需要几个测试：0 个属性、1 个属性、5 个属性、目标对象没有预期的属性、源对象没有预期的属性。现在，我可以在所有应用程序的其他地方重用这个通用映射引擎，并且不必每次使用时都检查它。
After mapping the first three properties, I would see the duplication and replace it by iterating over the properties and assigning them using reflection. That only needs a few tests: 0 properties, 1 property, 5 properties, target object doesn't have the expected properties, source object doesn't have the expected properties. Now I can reuse this general mapping engine everywhere else in all my applications and I don't have to check it each time I use it.