我拥有一个中等大小的nodejs应用程序(https://github.com/pgonzaleznetwork/sfdc-happy-soup)严重依赖第三方API。
简而言之，该应用程序所做的是基于输入参数和基于先前一些调用的响应来调用不同的Salesforce(低代码平台(API，包括REST和SOAP。这意味着一个请求的执行路径和API调用的数量可能与另一个请求完全不同。根据一些输入参数，该应用程序可以在一个请求中进行300多次API调用(通过作业的异步处理(。
考虑到API调用及其条件逻辑的复杂性，我很难弄清楚如何为此应用程序创建测试(mocha、jost等(。
大多数在线示例都是关于具有通用或可预测响应的简单端点，这些端点可以用之类的东西进行测试
assert(response)ToBe(200)
但是我的应用程序有太多不同的API，响应范围很广。
我可以通过单元测试分别模拟所有这些端点，但坦率地说，这似乎工作量太大，而且不会给我端到端的集成测试。
我还可以模拟一个完整作业的整个响应，并创建测试来断言处理该响应的代码正常工作，然而，我更感兴趣的是测试聚合所有这些API调用结果的数据转换代码。
更糟糕的是，大多数处理API的代码都封装在闭包中，这意味着我无法轻松地单独测试它们。如果没有模拟内部函数响应的方法，只测试外部函数是不可能的。
有人成功地为大量中继和转换第三方数据的应用程序创建了自动化集成测试吗？如果是，你能提供经验教训、模式等吗？
缓慢和不可靠
我知道您有很多API调用。如果您真的调用了第三方API，那么您将不得不等待它们。更糟糕的是，如果测试具有一些不可逆的影响(插入/更新/删除信息(，那么您的测试将使您的应用程序不可靠。避免对写操作进行自动化测试是不可接受的，因此实际调用API函数是需要避免的。
另一种选择
好吧，但如何避免呢？你会想要嘲笑的。请记住，您不是在测试第三方API，而是在测试它们的使用情况。所以，你的测试应该尝试有意义的场景。
规划有意义的场景
您拥有的每个API调用都可以有多个场景，这取决于您的期望。选择所有可能的响应(或它们没有响应，即拒绝/超时(的代表性案例，您的完整场景树将是可定义的，如：
如果API的第一次调用导致第二次API调用会是这样那样的，如果有的话。。。
自然地，您将能够修剪一些分支，就像您的第一个API请求超时的情况一样。在这种情况下，您可能希望通过尝试是否正确处理超时来完成测试。
重构代码
您已经提到，您需要在闭包中测试代码。这清楚地表明您的代码不太适合单元测试。您需要重构代码，确保要测试的代码不是依赖于封装代码，而是一个单独的函数，它接收参数，您可以在这些参数中传递以前由于关闭而自动知道的信息。这将把要测试的函数从它们的上下文中分离出来，这样你就可以自己测试它们了。
场景太多
你可能有太多的场景，这意味着你有很多工作要做。如果是这样的话，那么你可能想创建一系列规则。规则如下：
let dummyRule = {
called: 'API1',
formerResult: 'someresult1',
toBeCalled: 'API2'
expectedResult: 'expectedresult2',
parameters: {/*some object*/}
}
您将有一个测试用例的图形表示。您可以对图形进行深度优先或广度优先遍历，以生成所有实际场景。基于这些场景，您可以在源代码级别生成测试函数，假设您能够将所有自定义逻辑分离为可用函数。生成测试场景后，您只需将生成的文件集成到项目中即可。