5

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?

CC BY-SA 4.0
1

1 Answer 1

1

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.

CC BY-SA 4.0

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.