在Sveltekit&#x2B中嘲笑后端第三方呼叫剧作家

发布于 2025-02-09 11:49:51 字数 412 浏览 1 评论 0原文

这是关于设计模式/最佳实践的一个相当高的问题,在Sveltekit+playwright中开发端到端测试时:

推荐的方法是确保任何拨打3号的后端代码- 派对系统在E2E剧作家测试期间被固定/模拟吗?

在我的特殊情况下,我将我的hooks.js文件定义为将用户重定向到第三方登录服务。尝试访问受限制的URL。我想作为我的E2E测试的一部分来测试hook.js文件,但我不希望它每次都达到第三方服务。我想将此模式应用于我在测试涉及AWS S3的后端呼叫的流动时将遇到的类似问题。

我知道剧作家允许您模拟客户端执行的网络呼叫,但是我没有读过服务器端呼叫的类似功能。

有没有办法可以拦截hooks.js和其他后端处理程序触发的传出调用?

This is a fairly high-level question regarding design patterns/best practices when developing end-to-end tests in SvelteKit+Playwright:

What is the recommended way of ensuring that any back-end code that makes a call to a 3rd-party system is stubbed/mocked during e2e Playwright tests?

In my particular case, I have defined my hooks.js file to redirect users to a 3rd-party login services the moment a user attempts to access a restricted URL. I would like to test the hook.js file as part of my e2e tests, but I don't want it to hit the 3rd-party service each time. I would like to apply this pattern to a similar problem I will have when testing flows that involve back-end calls to AWS S3.

I know that Playwright allows you to mock network calls performed by the client, but I haven't read of similar capabilities for server-side calls.

Is there a way where I can intercept the outgoing calls triggered by hooks.js and other back-end handlers?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

绾颜 2025-02-16 11:49:51

剧作家不应该(也不应该是)选择的工具,可以帮助您模拟后端对第三方API的呼叫。在这种情况下,您可以使用 wiremock 。 WireMock是一个Web服务器,允许您定义Socalled stubs 对于您想嘲笑的API呼叫。这些模拟可以以JSON文件的形式定义:

{
  "request": {
    "method": "POST",
    "urlPath": "/path/to/reply/to/with/mock/response"
  },
  "response": {
    "status": 200,
    "body": "{\"sampleResponseField\":\"valueThatWouldNormallyBeProvidedByTheThirdPartyApi\"}",
    "headers": {
      "Content-Type": "application/json"
    }
  }
}

如果您的后端是Spring Boot应用程序您正在运行的WireMock独立实例的URL。您可以多种方式运行Wiremock。由于它是Java应用程序,您可以下载其jar file 并在本地或某些服务器上运行。他们还提供官方Docker Image 为此,您也可以在停靠的方式。因此,您也可以将其置于掌舵图中,以便能够部署&在kubernetes群集中运行(已经测试,也像魅力一样工作)。

无论您决定运行它哪种方式,您可能必须在application-e2etest.yml中调整WireMock实例的(基本)URL(仍然假设您有一个Spring Boot应用程序作为后端) 。如果您的后端基于其他框架,那么您很可能也有类似的方法来运行不同的配置。

为了快速了解它,我建议您以停靠的方式在本地运行Wiremock并将样本存根安装到其中:

docker run -d -p 8080:8080 --name wiremock -v ~/host/path/to/my/wiremock/stubs:/home/wiremock wiremock/wiremock:2.35.0

# And subsequently run a curl on it in order to check whether it responds as expected

curl http://localhost:8080/path/to/reply/to/with/mock/response

现在,Wiremock Server应使用先前在存根中定义的所需响应来回复。不要忘记将存根放在称为mappings的目录中,为 WireMock期望该存根在目录中以该名称位于目录中。

我希望这能让你前进。

PlayWright should not be (and can not be) the tool of choice to help you mock calls that your backend performs against third party API's. For such cases, you can, for instance, use WireMock. WireMock is a webserver that allows you to define socalled stubs for API calls that you want to mock away. These mocks can be defined in form of JSON files:

{
  "request": {
    "method": "POST",
    "urlPath": "/path/to/reply/to/with/mock/response"
  },
  "response": {
    "status": 200,
    "body": "{\"sampleResponseField\":\"valueThatWouldNormallyBeProvidedByTheThirdPartyApi\"}",
    "headers": {
      "Content-Type": "application/json"
    }
  }
}

If your backend is a Spring Boot application for instance, you could have an e2etest profile application-e2etest.yml in which your third party API url is exchanged with the url of the WireMock standalone instance you're running. You can run WireMock in multiple ways. As it is a Java application, you can download its JAR file and run in locally or on some server. They also provide an official Docker Image for it, so you can also run it in a dockerized way. Hence, you could also go a step further a wrap it into a Helm Chart in order to be able to deploy & run in within a Kubernetes cluster (already tested, works like charm as well).

Whatever way you decide to run it, you might have to adjust the (base) url of your WireMock instance within your application-e2etest.yml (still assuming that you have a Spring Boot application as your backend). If your backend is based on a different framework, you will most likely have a similar way in order to run your application with different configurations as well.

To get a quick feeling for it, I'd recommend you to run WireMock locally in a dockerized way and mount a sample stub into it:

docker run -d -p 8080:8080 --name wiremock -v ~/host/path/to/my/wiremock/stubs:/home/wiremock wiremock/wiremock:2.35.0

# And subsequently run a curl on it in order to check whether it responds as expected

curl http://localhost:8080/path/to/reply/to/with/mock/response

Now, the WireMock server should reply with the desired response you have previously defined in your stub. Don't forget to place your stubs into a directory called mappings, as WireMock expects the stubs to be located in a in directory with that name.

I hope this gets you going.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文