Creating fixtures with Playwright is a simple process that can greatly enhance

Question

Creating fixtures with Playwright is a simple process that can greatly enhance

I have a requirement to set up fixtures where the first fixture is always available (acting as a base class) and the second fixture will vary in different test files (like a derived class). I've implemented the following code which seems to be working as expected. Just wondering if this approach is acceptable or if there are better options out there?

//baseFixture.js
import { test as base} from '@playwright/test';
interface MyFixtures {
  fixture1: string;
}

export const test = base.extend<MyFixtures>({
  fixture1: "fixture-one"
}, );

//derivedFixture.js

import {test as test1} from 'baseFixture'
interface MyFixtures2 {
  fixture2: string;
}

export const test = test1.extend<MyFixtures2>({
  fixture2: "fixture-two"
}, );


//in test_file.js

import {test} from 'derivedFixture'

  test('should allow me use composed fixture', async ({ page, fixture1, fixture2 }) => {
     console.log(`from first fixture ${fixture1}`)
     console.log(`from second fixture ${fixture2}`)
  });

typescript playwright playwright-test

Answer 1

Answer №1

It appears that you may be utilizing fixtures like POMs and possibly overcomplicating your tests. If this approach suits your needs and aligns with your goals, then go ahead and use it. If my assumption is accurate, instead of passing fixtures to another fixture, consider passing POMs. You can even perform steps here to ensure a certain state is achieved for the page, as shown in this example from the playwright page:

// my-test.js
const base = require('@playwright/test');
const { TodoPage } = require('./todo-page');
const { SettingsPage } = require('./settings-page');

// Extend base test by providing "todoPage" and "settingsPage".
// This new "test" can be used in multiple test files, and each of them will get the fixtures.
exports.test = base.test.extend({
  todoPage: async ({ page }, use) => {
    // Set up the fixture.
    const todoPage = new TodoPage(page);
    await todoPage.goto();
    await todoPage.addToDo('item1');
    await todoPage.addToDo('item2');

    // Use the fixture value in the test.
    await use(todoPage);

    // Clean up the fixture.
    await todoPage.removeAll();
  },

  settingsPage: async ({ page }, use) => {
    await use(new SettingsPage(page));
  },
});
exports.expect = base.expect;

In your test, simply pass {todoPage} or {settingsPage}, or both:

const { test, expect } = require('./my-test');

test.beforeEach(async ({ settingsPage }) => {
  await settingsPage.switchToDarkMode();
});

test('basic test', async ({ todoPage, page }) => {
  await todoPage.addToDo('something nice');
  await expect(page.locator('.todo-item')).toContainText(['something nice']);
});

You can also chain your fixtures and reuse them. For example, you could pass todoPage to the settingsPage fixture:

  settingsPage: async ({ todoPage}, use) => {
    await use(new SettingsPage(page));
  },

This way, everything in todoPage will be executed before settingsPage, and this combined fixture is what you pass to your test, which I believe is what you were aiming for.

Answer 2

It appears that you may be utilizing fixtures like POMs and possibly overcomplicating your tests. If this approach suits your needs and aligns with your goals, then go ahead and use it. If my assumption is accurate, instead of passing fixtures to another fixture, consider passing POMs. You can even perform steps here to ensure a certain state is achieved for the page, as shown in this example from the playwright page:

// my-test.js
const base = require('@playwright/test');
const { TodoPage } = require('./todo-page');
const { SettingsPage } = require('./settings-page');

// Extend base test by providing "todoPage" and "settingsPage".
// This new "test" can be used in multiple test files, and each of them will get the fixtures.
exports.test = base.test.extend({
  todoPage: async ({ page }, use) => {
    // Set up the fixture.
    const todoPage = new TodoPage(page);
    await todoPage.goto();
    await todoPage.addToDo('item1');
    await todoPage.addToDo('item2');

    // Use the fixture value in the test.
    await use(todoPage);

    // Clean up the fixture.
    await todoPage.removeAll();
  },

  settingsPage: async ({ page }, use) => {
    await use(new SettingsPage(page));
  },
});
exports.expect = base.expect;

In your test, simply pass {todoPage} or {settingsPage}, or both:

const { test, expect } = require('./my-test');

test.beforeEach(async ({ settingsPage }) => {
  await settingsPage.switchToDarkMode();
});

test('basic test', async ({ todoPage, page }) => {
  await todoPage.addToDo('something nice');
  await expect(page.locator('.todo-item')).toContainText(['something nice']);
});

You can also chain your fixtures and reuse them. For example, you could pass todoPage to the settingsPage fixture:

  settingsPage: async ({ todoPage}, use) => {
    await use(new SettingsPage(page));
  },

This way, everything in todoPage will be executed before settingsPage, and this combined fixture is what you pass to your test, which I believe is what you were aiming for.

Answer 3

Answer №2

To increase efficiency, I implement the base fixture as a dependent fixture within a derivative fixture:

import { test as base } from "@playwright/test"
interface MyFixtures1 {
    fixture1: string
}

export const testBase = base.extend<{}, MyFixtures1>({
    fixture1: [
        async ({}, use) => {
            console.log("fixture1 setup once per worker")
            use("one")
            console.log("fixture1 teardown once per worker")
        },
        { scope: "worker" }
    ]
})

interface MyFixtures2 {
    fixture2: string
}

export const test = testBase.extend<MyFixtures2>({
    fixture2: async ({ fixture1 }, use) => {
        console.log("fixture2 setup for each test")
        use(`two-${fixture1}`)
        console.log("fixture2 teardown for each test")
    },
})

test("should allow me use composed fixture", async ({ fixture1, fixture2 }) => {
    console.log(`from first fixture ${fixture1}`)
    console.log(`from second fixture ${fixture2}`)
})

test("should base", async ({ fixture1 }) => {
    console.log(`from first fixture ${fixture1}`)
})

test("should derived", async ({ fixture2 }) => {
    console.log(`from second fixture ${fixture2}`)
})

For additional details on utilizing fixtures, refer to the official documentation

Answer 4

To increase efficiency, I implement the base fixture as a dependent fixture within a derivative fixture:

import { test as base } from "@playwright/test"
interface MyFixtures1 {
    fixture1: string
}

export const testBase = base.extend<{}, MyFixtures1>({
    fixture1: [
        async ({}, use) => {
            console.log("fixture1 setup once per worker")
            use("one")
            console.log("fixture1 teardown once per worker")
        },
        { scope: "worker" }
    ]
})

interface MyFixtures2 {
    fixture2: string
}

export const test = testBase.extend<MyFixtures2>({
    fixture2: async ({ fixture1 }, use) => {
        console.log("fixture2 setup for each test")
        use(`two-${fixture1}`)
        console.log("fixture2 teardown for each test")
    },
})

test("should allow me use composed fixture", async ({ fixture1, fixture2 }) => {
    console.log(`from first fixture ${fixture1}`)
    console.log(`from second fixture ${fixture2}`)
})

test("should base", async ({ fixture1 }) => {
    console.log(`from first fixture ${fixture1}`)
})

test("should derived", async ({ fixture2 }) => {
    console.log(`from second fixture ${fixture2}`)
})

For additional details on utilizing fixtures, refer to the official documentation

Creating fixtures with Playwright is a simple process that can greatly enhance

Answer №1

Answer №2

Similar questions

Nestjs: Can't find property in Mongoose document

What is the best way to include a variable or literal as a value in styled components?

In a situation where Typescript fails to provide enforcement, how can you effectively indicate that a function is not defined for specific value(s)?

Is it possible for Go's http server to compile TypeScript?

Signal a return type error when the provided element label does not correspond with an existing entity

Navigating conflicts between packages that utilize TypeScript can be tricky. Here are some strategies for handling these situations

"Encountering an issue with mounting components in React Unit Testing with Jest and Typescript

The art of crafting informative error log messages in Protractor using TypeScript

`Can you bind ngModel values to make select options searchable?`

Tips for obtaining a subset of `keyof T` where the value, T[K], refers to callable functions in Typescript

Next.js React Server Components Problem - "ReactServerComponentsIssue"

limiting the number of HTTP requests within a JavaScript forEach loop

The 'mergeMap' property is not found on the 'Observable<any>' type

Guide on utilizing a module in TypeScript with array syntax

Bidirectional data binding with Observable object

Having difficulty navigating to a different page in Angular 4

Avoiding multiple HTTP requests on various subscribers in RXJS/Angular

What is the best method for distributing an Angular service from a library created using ng generate library?

What is the reason for the lack of overlap between types in an enum?

"Troubleshooting: Child Component Not Reflecting Changes in UI Despite Using Angular