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