End 2 End Testing Use PlayWright

[reboottime]

Overview

This article gathers practices using PlayWright for End to End Testing.

check list

• networkidle

[reboottime]

Testing philosophy

Rule 1: Test user-visible behavior

• Automated tests should verify that the application code works for the end users. The end user will see or interact with what is rendered on the page, so your test should typically only see/interact with the same rendered output. (source)
• Ideally, locate elements using accessibility labels and roles, if possible.
• If not possible:
  • Use testId
  • You can configure Playwright-related ID with your own prefix

    import { defineConfig } from '@playwright/test';
    
    export default defineConfig({
      use: {
        testIdAttribute: 'data-pw'
      }
    });

Rule 2: Avoid testing third-party dependencies by mocking third-party responses

[reboottime]

When to mock and not mock API

Do not use API mocking when

• Testing the integration with the actual API: If the goal is to test the end-to-end integration between your application and the real API, mocking would defeat the purpose. In this case, you should test against the actual API.
• The API is stable and accessible: If the API is already stable, accessible, and not a performance bottleneck, there may be no need to mock it, as testing against the real API can provide more realistic results.
• Testing authentication or authorization flows: When testing authentication or authorization mechanisms that involve the actual API, mocking may not accurately represent the real-world behavior, and testing against the actual API is preferable.

Use API mocking when

• Testing against third-party APIs: If your application relies on external APIs that you don't control, it's better to mock those API responses during testing. This ensures your tests are reliable and not affected by the availability or behavior changes of the third-party API.
• API is under development: If the API your application will consume is still being developed or not yet available, you can mock the expected responses to continue testing the frontend application.
• Testing specific response scenarios: Mocking allows you to simulate various API response scenarios, including error cases, edge cases, or specific data scenarios that may be difficult to reproduce with the actual API.
• Improving test performance: Mocking eliminates the need to make actual network requests, which can significantly improve test execution speed, especially for large test suites or slow APIs.

[reboottime]

Fix flaky test

[reboottime]

Playwright configuration

Playwright use playwright.config.ts to configure test cases.

[reboottime]

Commonly used Code snippets

• Test selecting file
• Test downloading file

Newbie Errors

- Failed to intercept API