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

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(...){   ....}转换器具有一个公共方法和4个内部方法来转换实体。我应该如何测试？Option1 我仅测试公共方法，并通过不同的示例输入涵盖了internalMethods中的所有情况。优点：仅测试“接口”。不知道内部结构。内部重构非常容易，不需要在测试中进行任何更改。缺点：测试所有案例的测试可能很大，可能不清楚。每个输入都必须通过所有方法。Option2 我为公共方法和私有方法编写测试。（某些testframeworks可以访问诸如powermock或spock（groovy）之类的私有方法。）我单独测试每个方法并模拟其他每个内部方法。优点：真正的小型测试，仅测试方法本身并模拟所有其他方法。缺点：我知道它是如何内部实现的，如果我在内部调用结构上重构某些方法，某些方法名或某些内容，则必须更改测试Option3 我编写了一些新的类，这些类负责内部工作并具有公共方法优点：测试可能更清晰，并且仅针对特殊班级。缺点：一项转换任务需要更多类。请帮助我，这里的最佳做法是什么。也许一些良好的链接/提示。感谢您的时间。

Answer 1

您提出的观点是正确的，但我认为您可能无法正确估算它们的权重。

编写易碎的测试（与实现代码耦合的测试）会导致难以更改的刚性代码库。由于编写测试的第一要点是能够快速进行，因此适得其反。

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

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

我的建议是，使用重构1中描述的方式编写代码，然后在需要时提取代码。