如何测试转换器之类的东西答案

【问题标题】：How to testing something like a converter如何测试转换器之类的东西
【发布时间】：2018-07-15 10:23:07
【问题描述】：

我有一个关于像转换器这样的测试类的问题。假设我有一个从 EntityA 到 EntityB 的转换器。转换器看起来像这样：

public EntityB convert(EntityA){
     //call interal methods
     return B.
}

private xy internalMethod1(...){
   //call other interal Method
}

private xy internalMethod2(...){
   ....
}

private xy internalMethod3(...){
   ....
}

private xy internalMethod4(...){
   ....
}

转换器有 1 个公共方法和 4 个内部方法来转换实体。

我应该如何测试它？

选项1 我只测试公共方法并通过不同的示例输入涵盖来自 internalMethods 的所有情况。

优点：仅测试“接口”。不知道内部结构。内部重构非常简单，无需在测试中进行任何更改。

缺点：测试所有情况的真正大的可能不清楚的测试。每个输入都必须通过所有方法。

选项2 我为我的公共方法和私有方法编写测试。（一些测试框架可以访问私有方法，如 powermock 或 spock (groovy)）我单独测试每个方法并模拟所有其他内部方法。

优点：真正的小测试，只测试方法本身并模拟所有其他方法。

缺点：我知道它是如何在内部实现的，如果我在内部调用结构中重构某些方法、某些方法名或某些东西，则必须更改测试

选项3 我写了一些新的类来做内部的事情并有公共方法

优点：测试可能更清晰，并且仅适用于特殊课程。

缺点：一个转换任务的更多类。

请帮助我这里的最佳做法是什么。也许有一些好的链接/提示。感谢您的宝贵时间。

【问题讨论】：

标签： java unit-testing testing tdd

【解决方案1】：

你提出的观点是正确的，但我认为你可能没有正确估计它们的重量。

编写脆弱的测试（与实现代码耦合的测试）会导致难以更改的僵化代码库。由于首先编写测试的目的是为了能够快速运行，因此会适得其反。

这就是您仅通过 API 编写测试的原因——它将测试与实现分离。正如您所说，这可能会使编写测试变得更加困难，但值得付出努力，因为您将获得安全并能够轻松重构。

当您看到代码异味时，选项 3 就会发挥作用，即某些测试仅涵盖部分代码，而其他测试仅涵盖代码的其他部分。这通常意味着可能需要提取一个合作者。当某些内部函数仅使用某些参数而其他不使用时，尤其如此。还有，当有代码重复之类的时候。

我的建议是使用您在选项 1 中描述的方式编写它，然后在重构阶段根据需要提取代码。

【讨论】：