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