我正在开发一个项目，该项目与调用外部服务的API相关联。事情进展顺利，但我们需要开始一些严肃的测试。有趣的部分？绝大多数对这项服务的调用都要经过一个庞大的类（我们称之为Mastadon.class。这似乎很合适。）在API中。 Mastadon中有大量的方法用于进行各种不同的调用，而我们的项目使用了大量的方法。其中一些只是公共便利方法，可以将内容反弹给私人方法，但数量仍然很大。
所以现在测试的乐趣来了。我们当然希望避免不停地打电话给这项服务。有些测试甚至需要在另一端采取某些操作，并且从服务发回某些操作/结果，我们必须手动完成或者在另一端做一些奇特的自动化工作，我们宁愿不做做。
我们可以为Mastadon类创建一个mock子类，但这有很多方法可以存根，我们可能需要根据测试和输入而改变行为。这是很多傻瓜。我们可以使用一个模拟框架（我们目前使用JMockit进行某些操作），但同样，这是对服务的大量嘲弄，嘲弄可能是一个真正的痛苦。我还考虑做一些重组工作来制作一个可注入的代理类（可能不是我在这里寻找的精确短语，但你得到了这个想法），它充当了我们的代码和Mastadon类的中介。我们的代码永远不会真正触及Mastadon，而是使用MastadonProxy或我们称之为传递呼叫的任何内容。这将意味着一些项目的重组和进一步的工作，但从长远来看可能会更容易，因为我们可以构建一个MastadonTestProxy并且只存在那里需要的东西，甚至可能有一些注入行为。它将比MastadonTest类更简单，它使用bajillion方法简单地引用父Mastadon方法，因为我们不需要特别测试那个。
你说什么？这个API似乎没有考虑到测试。我们确实拥有整个事物的源代码，但如果能够得到帮助，我宁愿不对它进行任何更改。我倾向于注入代理类，但也许有更好的方法来处理它，特别是在端到端集成测试时。
编辑： 我还意识到代理类可能无法正常工作，因为API中有许多其他对象都有自己的便利方法，最终也会通过Mastadon。所以ObjectA可能有一个doThis（）方法，它在幕后通过Mastadon的doThis（）方法结束。我认为类扩展/模拟大道可能是唯一的方法......
编辑：另一个问题。 Mastadon继承自一个略小的抽象类，它还有另一个子类。我需要为它们中的所有三个都设置一个外观，但这让我有了解决如何以一种实际工作的方式正确地覆盖所有这些类的乐趣。另外，我需要保留每个方便的实例（或工厂在需要时创建它们）来传递调用，并且需要有一些状态，可能是变量中的变量等等。答案 0 :(得分：0)
我建议你花些时间使用你认为正在考虑的两种方法的组合来建立一个合适的测试框架。
（1）使用假注射资源代理该类中的功能，
（2）使用该类/包装接口的测试扩展来隐藏您不需要的功能。这就是JMock令人惊叹的地方 - 至少有一半它可以帮助你的东西将成为非常好的惊喜。
虽然起初这可能看起来像是一项非常多的工作，但它是构建灵活且可扩展的自动化/回归测试框架的最佳方式。除非你打算为你在“Mastodon.class”上构建的每个未来项目重做同样的工作，否则这听起来像你应该/应该去的那样。
如果你想要一些大事，最好付出一些努力。记住写代码是什么样的......：一个错误，你必须在余生中支持它。