We run two projects against the same design system: same header, same login form, same data grid, different products around them. The login page object is now duplicated in projects/storefront/pages/ and projects/admin/pages/, and they have already drifted.
Is there a supported way to share the class, something at the workspace level maybe, or is copying the intended answer?
Accepted answer
There is no supported mechanism, and two things stand in the way of an obvious one.
The step glob per project is the core library plus that project's own steps/**/*.ts and pages/**/*.ts. A class living in a package elsewhere in the monorepo is simply never loaded, so its decorators do nothing. And @Fixture<typeof test>('loginPage') binds to the test exported from that project's steps/fixtures.ts — a different project has a different test with a different fixture map. Workspace defaults in sdods.workspace.yaml cover browsers, suites and the test-id attribute; they do not cover code.
What we do, and what I have seen elsewhere: split the class in two.
// packages/design-system-pages/src/LoginSurface.ts — no decorators, no @Fixture
export class LoginSurface extends BasePage {
readonly username = this.heal.locator(this.page.getByLabel('Username'), {
label: 'Username',
testId: 'username',
description: 'username input',
});
async signIn(user: string, password: string) {
await this.username.fill(user);
}
}// projects/storefront/pages/LoginPage.ts — thin, decorated, project-owned
@Fixture<typeof test>('loginPage')
export class LoginPage extends LoginSurface {
@Given('I am on the login page')
async open() {
await this.goto('login');
}
}The locators are shared; the route names, the fixture registration and the step text stay with the project that owns them.
That is the right shape, with one caution about how far to take it.
Two projects that look like they share a page usually differ in exactly the places that matter: the route path, the test-id attribute, whether a field is required. Sharing the locators is cheap. Sharing the step text is where it goes wrong, because Given I am on the login page then means two different things depending on which project the feature file is under, and the person reading a failure has no way to tell which.
Share the surface. Let each project spell out its own Gherkin.
Have the same question?
Ask it with the command you ran and the output you got, and it will be answered here.
Ask a question