单元测试对象转换器答案

【问题标题】：Unit Testing Object Converters单元测试对象转换器
【发布时间】：2016-02-11 20:29:38
【问题描述】：

您如何测试或根本测试将某些其他数据模型/结构转换为您的数据模型的类？

interface ToTradeObjectConverter<T> {
    public Trade convertToTrade (T source);
}

public class Trade {
    // here we have ~ 100 fields, like dates, account, currencies, etc.
}

转换器只是通过设置器填充Trade，从另一个对象获取数据或解析文本或XML 或其他任何东西。

你会测试这样的课程吗？如果是这样，什么是好的方法？我不想模拟 (EasyMock) 参数并添加 100 行“简单模拟期望调用正确的 getter 和 setter”。

【问题讨论】：

标签： unit-testing testing

【解决方案1】：

如果这些类是自动生成的，或者它们是手写的，但从不对输入做任何有趣的事情（他们只是复制它），并且如果你有集成覆盖，我不会测试它们。（我是从 BDD 的角度出发：首先通过验收/集成测试，然后根据需要对其余部分进行单元测试。）

如果这些类做了一些有趣的事情，和/或如果它们没有集成覆盖，请测试它们。

我绝对不会使用嘲笑。这些似乎是在内存中完成所有工作的简单类。我认为在没有太多痛苦的情况下测试这些类的秘诀是为它们提供所有强大的 .equals 方法（如果它们还没有的话）。您可能可以生成它们。然后您的单元测试将类似于

public class ToTradeObjectConverterTest {
  @Test
  public void convertToTradeReturnsTheExpectedObject() {
    TradeSource source = new TradeSource(/* whatever goes here */);
    Trade trade = new ToTradeObjectConverter<TradeSource>().convertToTrade(source);
    Trade expectedTrade = new Trade(/* whatever goes here */);
    assertThat(expectedTrade, equalTo(trade));
  }
}

【讨论】：

同意你的代码。只是想知道也许有人想出了灵魂来避免创建具有数百个字段的真实对象。
我只是在回答你提出的问题，但我同意——如果你的系统有很多这样的类，你应该重新考虑你的架构。源类和转换后的类都做有趣的工作吗？如果没有，也许您可以将它们替换为单个源类和/或以通用方式保存数据的单个转换类。或者，也许您可以将它们替换为 JSON 文档之类的。
类没有逻辑，只是承载数据。但我坚持将域模型作为大多数数据的包装器。因此，假设我们有 Price 类，而不是将属性“价格”作为 BigDecimal。使用一个类或使用地图或 json 文档等数据持有者不是正确的 OOP 方法。但是你给了我一个想法：我会用什么来介绍我的所有数据类型，比如说地图。
这里的好论据：yojava.wordpress.com/2011/06/17/…
我也喜欢真正的领域对象。您只需要确定它们是否在您的架构中提供了足够的价值来证明创建和测试它们的努力是合理的。我想说的是，如果您有一个贫血的域模型 (stackoverflow.com/questions/258534/…)，那么该模型是手写的、代码生成的还是存储在（类型检查的）文档中都没有关系。