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...

Playwright Solution

 There is a web site need to run with browser. and which has zero downtime and alert and notifications pop up too. Third party applications are involved in and need to fix bugs too.What is the solution and how to create a framework for this scenario : need to use playwright as well 1. Understand the Requirements and Challenges: Zero Downtime: Ensure tests do not interrupt the service. Alerts and Notifications: Handle unexpected pop-ups gracefully. Third-Party Integrations: Test interactions with third-party services. Bug Fixing: Implement a process to identify and log bugs efficiently. 2. Set Up the Playwright Framework: Installation: Ensure Playwright is installed and configured. bash Copy code npm install playwright 3. Structure the Test Framework: Test Suites: Organize tests into suites (e.g., smoke tests, regression tests, integration tests). Page Object Model (POM): Use POM to manage page elements and actions. Configuration: Set up configurations for different envir...

Challenges

 One of the challenging situations I faced was identifying the correct locators for elements in our Angular application. Despite using developer tools like Chrome DevTools, it was often difficult to pinpoint the exact locators due to the complexity of the application and the dynamic nature of Angular's rendering. To overcome this, I frequently had to review the application's code in Bitbucket to understand the structure and find reliable locators. This approach allowed me to write more robust and reliable tests. Additionally, I communicated with developers to gain insights and confirm my findings, which helped streamline the process." As our application grew, the number of test scripts also increased, making the scripts larger and more chaotic. This was especially true for our end-to-end tests using Playwright and TypeScript. The test scripts became hard to manage and maintain because they contained both the test logic and the test data, leading to a lot of redundancy and ...