我正在开发一个与调用外部服务的 API 相关的项目。事情进展顺利，但我们需要开始一些严肃的测试。有趣的部分？对该服务的绝大多数调用都通过 API 中的一个巨大的类（我们称之为 Mastadon.class。它似乎很合适。）。Mastadon 中有大量的方法可以进行各种不同的调用，我们的项目使用了大量的方法。其中一些只是将事情反弹到私人的公共便利方法，但数量仍然很大。
所以现在测试的乐趣来了。我们当然希望避免不断调用此服务。一些测试甚至需要在另一端采取某些行动，并从服务发回某些行动/结果，我们必须手动完成或在另一端做一些花哨的自动化工作，我们宁愿不这样做做。
我们可以为 Mastadon 类创建一个模拟子类，但要存根的方法很多，而且我们可能需要根据测试和输入来改变行为。这是很多的恶作剧。我们可以使用一个模拟框架（我们目前在某些事情上使用 JMockit），但同样，这是对服务的大量嘲弄，而模拟可能会让人头疼。我还考虑过进行一些重组来制作一个可注入的代理类（可能不是我在这里寻找的确切短语，但你明白了）充当我们的代码和 Mastadon 类的中间人. 我们的代码永远不会真正触及 Mastadon，而是使用 MastadonProxy 或我们称之为的任何东西来传递调用。这将意味着对项目进行一些重组和进一步的工作，但从长远来看可能会更容易，因为我们可以构建一个 MastadonTestProxy 并只存根那里需要的东西，甚至可能有一些可注入的行为。它会比一个 MastadonTest 类少很多，它有一个简单地引用父级 Mastadon 方法的 bajillion 方法，因为我们不需要特别测试那个方法。
你说什么？这个 API 在构建时似乎没有考虑到测试。我们确实有整个事情的源代码，但如果有帮助的话，我们不希望对其进行任何更改。我倾向于可注入代理类，但也许有更好的方法来处理这个问题，尤其是在端到端集成测试方面。
编辑：我还意识到代理类可能无法工作，因为 API 中有许多其他对象具有自己的便利方法，最终也会通过 Mastadon。所以 ObjectA 可能有一个 doThis() 方法，最终会在幕后通过 Mastadon 的 doThis() 方法。我认为类扩展/模拟途径可能是解决这个问题的唯一方法......
编辑：另一个问题。Mastadon 继承自一个稍小的抽象类，该抽象类也有另一个子类。我需要为所有三个类中的所有内容都设置一个外观，但这让我很高兴能够整理出如何以一种实际可行的方式正确地对所有这些类进行外观。此外，我需要保留每个方便的实例（或在需要时创建它们的工厂）以传递调用，并且需要一些状态，可能是其中的变量更改等。