我正在使用Phoenix API开发Ember.js应用程序。 我遵循某人的建议将UI和API保留为单独的项目，并且我知道我可以在开发和测试期间使用ember-cli-mirage来模拟我的API。 但这让我真的很紧张。 我习惯于使用一组集成测试来一起测试UI和API。 我知道，有一天，我或另一位开发人员将对其中一个项目进行重大更改，并且直到用户开始抱怨时我们才意识到这一点。
另一方面，我真的很喜欢在运行Ember.js的客户端中模拟API的想法。 它应该使开发和测试真正快速。
有没有一种方法可以提取我的API端点的高级描述，并将其用作健全性检查，以确保我的模拟API满足所有要求？ 例如，如果我在API服务器中添加或删除路由，如果模拟的API与那些更改不匹配，我希望Ember.js测试立即失败。 因为我知道这将有一天发生。 如果要在成功构建后使用连续部署，则尤其要注意。
还是应该在CI机器上启动真正的API服务器，然后针对该服务器运行测试？
我有点喜欢执行API合约的想法。 我还可以在以后的任何移动或桌面应用程序中重用该原理。 您可以获得一定的一致性保证，而不必安装大量依赖项并启动真正的API。
另一个想法：也许我编写了一组API接受测试，但同时针对真实的API和模拟的API运行它们。 然后，我可以在主API存储库中包含模拟的API代码（ember-cli-mirage），并将其作为子模块链接到Ember.js存储库中。
人们目前如何处理此问题？
您的Ember测试应重点关注客户端应用程序本身的行为，而不是API的实现细节。 虽然在ember-cli-mirage中维护API逻辑的单独模拟实例会比较麻烦，但实际上，您仅应按照Ember测试的要求添加Mirage端点和行为。
如果您向API服务器添加路由，并且没有Ember代码与之交互，则无需编写消耗模拟的Mirage端点的Ember测试。
如果您在API中删除路由或更改行为，则可以使所有受影响的Ember测试立即失败，但是重写这些Ember测试和Mirage端点以反映新行为只是业务上的代价。
从长远来看，这还有更多工作要做，但是我认为，如果将Mirage中的API和模拟的端点视为单独的关注点，则测试将更有意义。 您的Ember测试不应测试您的服务器是否正常工作-它们仅应在已知约束条件下验证您的Ember代码是否正常工作。
避免测试套件中遗漏的一种方法可能是强制实施一项（人为的）策略，其中对API行为的任何更改都在正式的测试DSL（例如Gherkin）中指定 ，至少要记录需求，然后将其作为单个用于编写将实现更改的新测试和代码的参考。