Tips & Tricks : Mocking APIs With Playwright

Hello, everyone. This brief blog post is the first in a series of tips, tricks and best practices that QA engineers should be aware of to enhance their testing approach. I will highlight the benefits of mocking API responses and demonstrate how you can achieve this using Playwright.

As we are aware, in the testing pyramid, the largest portion of the system is covered by unit testing, followed by integration testing, and finally, end-to-end (e2e) testing. By efficiently maintaining this approach, our e2e testing can be more focused on high-priority, critical use cases, and user stories. Consequently, this approach helps us avoid overwhelming our backend with a multitude of API requests due to the high volume of test cases, leading to more efficient and effective testing.

Mocking APIs means simulating or manipulating the behavior of the API during testing. It allows you to intercept and control API requests and their responses without actually generating real network traffic, thereby avoiding overwhelming the backend especially if you want to scale up you tests.

Mocking APIs is an efficient technique that can enhance our E2E automation tests. It helps “isolate our test cases”, enabling them to focus on user stories and system behavior without relying on external services or API availability. Consequently, this approach makes our tests more stable, reliable, and less prone to flakiness.

Furthermore, mocking APIs facilitates the creation of more complex “test scenarios” that might be challenging to implement without mocking since these scenarios might rely on specific responses such as success, errors, timeouts, status codes, and specific data, which can be difficult to maintain through the frontend alone.

Using this approach enhances “test efficiency” since mocking APIs is faster than relying on live APIs. With full control over API responses, you can easily avoid delays. Additionally, this leads to “cost reduction” as it eliminates the need to use live APIs, which may consume expenses.

Playwright mocks APIs in a straightforward manner. I will demonstrate a couple of approaches through which we can learn how to do this. The first approach involves mocking the API response without making an actual request to the endpoint. Then, we’ll load the page associated with this mocked API.

In the snippet below, I have mocked the response associated with an endpoint called “/feedback” using the following code snippet.

    await page.route('http://localhost:3022/feedback', async (route) => {
      const json = [
        {
          id: 55,
          title: "Title: amr salem",
          body: "This is a mocked feedback",
          author: {
            id: 11,
            username: "Amr",
          },
          receiver: {
            id: 21,
            username: "smith",
          },
        },
      ];
      await route.fulfill({ json });
    });
    await page.goto("/feedback");

We start by identifying the API endpoint route, followed by specifying the JSON object, which includes setting the content type as “application/json” and defining the response body. This allows us to seamlessly incorporate the necessary assertions and encapsulate the entire process within our test block.

  test("[Desktop] Should be able to mock api response", async ({ page }) => {
    await page.route('http://localhost:3022/feedback', async (route) => {
      const json = [
        {
          id: 55,
          title: "Title: amr salem",
          body: "This is a mocked feedback",
          author: {
            id: 11,
            username: "Amr",
          },
          receiver: {
            id: 21,
            username: "smith",
          },
        },
      ];
      await route.fulfill({ json });
    });
    await page.goto("/feedback");
    await expect.soft(page.getByText("This is a mocked feedback")).toBeVisible();
  });

We can also intercept the actual API response and inject/modify the existing response body, as demonstrated below.

  test("[Desktop] Should be able to mock api response", async ({ page }) => {
    await page.route('http://localhost:3022/feedback', async (route) => {
      const response = await route.fetch();
      const json = await response.json();
      json.push({
        id: 55,
        title: "Title: amr salem",
        body: "This is a mocked feedback",
        author: {
          id: 11,
          username: "Amr Salem",
        },
        receiver: {
          id: 21,
          username: "smith",
        },
      });
      await route.fulfill({ json });
    });
    await expect.soft(page.getByRole("heading", { name: "Title: amr salem" })).toBeVisible();
    await expect.soft(page.getByText("This is a mocked feedback")).toBeVisible();
  });

As shown above, the endpoint has been called twice: first to reach the actual endpoint and then to mock its response by injecting our own object among other. This approach is particularly useful when testing dynamic data that undergoes constant changes, allowing you to assess its behavior when modifications are made.

Similarly, you can also mock API headers, status codes, paths, and content types to align with your test scenarios.

In conclusion, using API mocking can significantly enhance your automation framework in several ways. It enhances reliability by isolating your tests and reducing dependency on API availability. It also accelerates execution since you are not making live API calls, and it expands your testing coverage by allowing the implementation of more complex test cases that can be challenging to maintain with traditional approaches.

Thank you for taking the time to read my blog — I hope it provided some insight and value into your project. Stay tuned for the new upcoming interesting blogs…