Skip to main content

Fixtures

 In Playwright, a fixture refers to a predefined setup or configuration that provides the context for your tests. Fixtures are used to define the environment in which tests run, ensuring that necessary prerequisites are in place before the execution of each test or suite of tests. Fixtures can include actions like launching a browser, setting up test data, initializing objects, or any other setup needed to ensure consistent and reliable test execution.

Key Concepts of Fixtures in Playwright

  1. Setup and Teardown: Fixtures handle the setup and teardown processes, making sure that the environment is correctly prepared before a test runs and cleaned up afterward.
  2. Isolation: Fixtures help isolate tests from each other, ensuring that tests do not interfere with one another by sharing the same state or data.
  3. Reusable Configurations: Fixtures allow for the reuse of common setups across multiple tests, reducing redundancy and making the test code cleaner and more maintainable.

Normally, if all tests pass and no errors are thrown, the order of execution is as following.

  • worker setup and beforeAll section:
    • browser setup because it is required by autoWorkerFixture.
    • autoWorkerFixture setup because automatic worker fixtures are always set up before anything else.
    • beforeAll runs.
  • first test section:
    • autoTestFixture setup because automatic test fixtures are always set up before test and beforeEach hooks.
    • page setup because it is required in beforeEach hook.
    • beforeEach runs.
    • first test runs.
    • afterEach runs.
    • page teardown because it is a test-scoped fixture and should be torn down after the test finishes.
    • autoTestFixture teardown because it is a test-scoped fixture and should be torn down after the test finishes.
  • second test section:
    • autoTestFixture setup because automatic test fixtures are always set up before test and beforeEach hooks.
    • page setup because it is required in beforeEach hook.
    • beforeEach runs.
    • workerFixture setup because it is required by testFixture that is required by the second test.
    • testFixture setup because it is required by the second test.
    • second test runs.
    • afterEach runs.
    • testFixture teardown because it is a test-scoped fixture and should be torn down after the test finishes.
    • page teardown because it is a test-scoped fixture and should be torn down after the test finishes.
    • autoTestFixture teardown because it is a test-scoped fixture and should be torn down after the test finishes.
  • afterAll and worker teardown section:
    • afterAll runs.
    • workerFixture teardown because it is a workers-scoped fixture and should be torn down once at the end.
    • autoWorkerFixture teardown because it is a workers-scoped fixture and should be torn down once at the end.
    • browser teardown because it is a workers-scoped fixture and should be torn down once at the end.

Comments

Popular posts from this blog

Get OTP from email

/** * Retrieves an OTP from Gmail in a headless tab. * @param {Object} options - The options for the function. * @param {string} options.email - The Gmail email address. * @param {string} options.password - The Gmail password. * @returns {Promise<string | null>} The OTP retrieved from the email. */ export async function getOtpFromGmail ({ email , password , } : { email : string ; password : string ; }) : Promise < string | null > { const { chromium } = require ( "playwright" ); // Launch a headless browser context for Gmail login const browser = await chromium . launch ({ headless : true }); const context = await browser . newContext (); const page = await context . newPage (); await page . goto ( "https://mail.google.com" ); const emailInput = await page . waitForSelector ( "#identifierId" ); await emailInput . fill ( email ); const emailNextButton = await page . wa...

Mock server

 Using a mock server in end-to-end (E2E) testing is indeed common, and it can be used for more than just reading values. Mock servers simulate the behavior of real servers and can handle various HTTP methods, including POST , PUT , DELETE , and PATCH , in addition to GET . This means you can use a mock server to simulate interactions that involve writing data, such as filling out and submitting forms. Automating Form Interactions with Mock Servers Simulating Form Submissions : Mock servers can be set up to handle form submissions. When you submit a form in your E2E test, the mock server can capture the request and respond with a predefined response. Validating Data : You can use the mock server to validate the data sent by your application. The mock server can check if the request body matches the expected format and values. Response Handling : After submitting a form, your application typically processes the server's response. The mock server can provide specific responses to test...

Browser Context

 In the context of Playwright, understanding how pages and browser contexts work is crucial for managing test isolation and ensuring reliable test execution. Here’s an explanation: Browser Context in Playwright Definition : A browser context in Playwright is akin to a new browser profile. Each browser context provides a separate environment where cookies, local storage, and other session data are isolated from other contexts. Isolation Between Tests : When you run tests using Playwright, each test typically operates within its own browser context. This means that: Fresh Environment : Every test starts with a clean slate, ensuring that any changes made by one test (such as cookies or session data) do not affect subsequent tests. Consistent State : Tests are independent of each other in terms of state, which helps in avoiding interference between different test cases. Page Isolation : Within each browser context, individual pages (created using page objects in Playwright) are also i...