我想编写一个具有简单前端-后端（REST API）架构的 Web 应用程序。 我不清楚在哪里以及如何编写测试。
前端：我应该编写模拟 API 响应并仅测试 UX/UI 的测试吗？ 后端：我应该在这里编写 API 调用测试，并最终对类进行更细粒度的单元测试吗？
但是以这种方式，我担心前端测试不知道真正的 API 响应（因为它是独立于后端进行模拟的）。 另一方面，如果我不模拟 API 响应并使用来自后端的真实响应，那么前端客户端如何准备 DB 以获取他想要的数据？
在我看来，我需要 3 种测试类型： - UX/UI 测试：前端正在处理一组模拟响应 - API 测试：API 给出一组数据的正确答案 - 集成测试：前端通过使用一组数据（由谁生成？）调用真正的后端来工作。
是否有框架或工具可以让这一切变得尽可能轻松？ 在我看来这很复杂（如果 API 规范发生变化，我必须重写很多测试）
欢迎提出建议
【问题讨论】：
标签： rest testing frontend backend
嗯，你基本上是对的。在这个场景中有 3 种类型的测试：后端逻辑、前端行为和集成。让我们拆分它：
后端测试
您主要测试应用程序的业务逻辑。但是，您必须测试整个应用程序堆栈：域、应用程序层、基础设施、表示 (API)。这些层需要单元测试和集成测试，以及从用户角度来看的一些纯黑盒测试。但这本身就是一个复杂的问题。完整的答案将非常长。如果您对一般测试应用程序的一些技术感兴趣 - 请启动另一个线程。
前端行为
在这里您可以测试前端应用程序是否以正确的方式使用 API。您模拟后端层并主要编写单元测试。现在，正如您所注意到的 - 实际 API 合同可能存在一些问题。但是，有一些方法可以缓解此类问题。首先，指向这些解决方案之一的链接：https://github.com/spring-cloud/spring-cloud-contract。现在，一些解释。这个想法很简单：API 合约由消费者驱动。在您的情况下，这将是前端应用程序。前端团队与后端团队合作创建一个合理的 API，满足客户的所有需求。因此，前端测试保证使用“真正的 API”。当客户端测试发生变化时——合同发生变化，因此后端必须重构以适应新的需求。
附带说明 - 您实际上并不需要使用任何具体的框架。如果你对你的团队应用一些纪律，你可以遵循相同的方法。请记住 - 消费者首先定义合同。
集成测试
为确保一切正常，您还需要进行一些集成 e2e 测试。您设置了后端应用程序的真实测试实例。然后，您使用真实服务器而不是假的模型响应执行集成测试。但是，您不需要（也不应该）从其他层复制相同的测试。您想测试是否所有内容都正确集成。因此，您无需测试任何真正的逻辑。您只需选择一些快乐的路径，也许是一些失败的场景，然后从用户的角度执行这些测试。因此，您无需假设后端应用程序的状态并模拟用户交互。像这样：添加新产品、修改产品、获取更新的产品或检查单个身份验证点。那种测试 - 不是真正测试任何业务逻辑，但前提是真正的 API 测试服务器与前端应用程序正确通信。
【讨论】：