Network and API

Abort and Continue Network Requests

Abort and Continue Network Requests: definition, route.abort, route.continue, examples, mistakes, interview notes, and practice.

Definition and Brief Explanation

Definition: Abort and continue control intercepted network requests by either blocking them or allowing them to proceed, optionally with changes.

Explanation: Abort is useful for testing blocked resources or failed calls. Continue is useful when you want to inspect or slightly modify a request while still using the real backend.

Why It Matters

  • It makes tests faster and more controlled when backend state matters.
  • It lets you test success, failure, and edge cases without depending on unstable services.
  • It helps verify that the UI sends or receives the expected API traffic.
  • It supports clean setup for UI tests through API calls.

How It Works

  1. Identify the request or API state involved in the test.
  2. Set up the route, request context, or response wait before the UI action.
  3. Trigger the UI behavior.
  4. Assert both the page result and important request/response details when needed.

Syntax and Examples

Example 1: Abort images

await page.route('**/*.{png,jpg,jpeg}', route => route.abort());

Explanation: Blocks matching image requests.

Example 2: Continue API request

await page.route('**/api/**', route => route.continue());

Explanation: Allows matching requests to continue to the real server.

Common Mistakes

  • Mocking so much that the test no longer checks real integration.
  • Using URL patterns that match unrelated requests.
  • Creating shared backend data that breaks parallel tests.
  • Forgetting the UI assertion after network setup.

Interview Notes

  1. What problem does Abort and Continue Network Requests solve?
  2. When would you mock instead of using the real API?
  3. How do you avoid over-mocking?
  4. How do network waits differ from UI assertions?

Practice Task

Create a small Playwright example for Abort and Continue Network Requests. Add one positive assertion, one note about what can go wrong, and one improvement that would make the test more maintainable.