Skip to content

[Feature]: access project options in beforeMount hook #35037

Open
@mihkeleidast

Description

@mihkeleidast

🚀 Feature Request

Allow access to project options in beforeMount hook, similarly to how they are provided to test function as params.

Example

beforeMount<HooksConfig, ProjectConfig>(async ({ App, hooksConfig, projectConfig }) => {
  return (
    <ThemeProvider brand={projectConfig.brand} theme="projectConfig.theme">
      <App />
    </ThemeProvider>
  );
});

or something like that - providing access to the test project options directly.

Motivation

We use playwright to run visual regression tests across multiple brands and themes. For example, the projects config looks like this:

projects: [
    {
      name: 'brand-a-light',
      use: {
        brand: 'brand-a',
        theme: 'light',
      },
    },
    {
      name: 'brand-a-dark',
      use: {
        brand: 'brand-a',
        theme: 'dark',
      },
    },
    {
      name: 'brand-b-light',
      use: {
        brand: 'brand-b',
        theme: 'light',
      },
    },
    {
      name: 'brand-b-dark',
      use: {
        brand: 'brand-b',
        theme: 'dark',
      },
    },
  ]

Now, these brand and theme params need to be passed into a ThemeProvider component that does some global setup so the components in it render correctly:

test('renders', async ({ mount, page, brand, theme }) => {
  await mount(
    <ThemeProvider brand={brand} theme={theme}>
      <TestComponent />
    </ThemeProvider>,
  );
  await expect(page).toHaveScreenshot();
});

Currently, we have to have this exact ThemeProvider wrapper around every single one of our tests, resulting in a lot of duplications.

I'm aware that it's possible to send the test params to hooks via hooksConfig, but that would still mean that every single test needs to do that, so it's still quite a bit of duplications.

I understand that the beforeMount hook is meant for things like these - setting up globals so tests can focus on what they are for - so accessing project options to set up the global wrappers sounds the logical thing to do.

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions