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

Question

我有一个关于像转换器一样测试类的问题。假设我有一个从 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(...){
   ....
}

转换器有一个public方法和4个内部方法来转换实体。

我应该如何测试它？

选项 1 我只测试 public 方法并通过不同的示例输入覆盖 internalMethods 的所有情况。

优点：仅测试 "interface"。不知道内部结构。内部重构非常简单，测试时无需更改。

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

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

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

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

选项 3 我写了一些新的类来做内部的东西并且有 public 方法

优点：测试可能更清晰，并且只针对特殊的类.

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

请帮我看看这里的最佳做法是什么。也许有些好links/hints。谢谢你的时间。

Answer 1

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

编写脆弱的测试（与实现代码耦合的测试）会导致难以更改的刚性代码库。由于编写测试的首要目的是能够快速进行，这适得其反。

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

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

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

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

How to testing something like a converter

java

unit-testing

testing

tdd