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