Example threads. These questions and answers were written by the SDODS team to document real problems and how to fix them. The people named are illustrative, not real users. Questions asked on this site are marked new.
I put my page object in projects/demo-shop/support/pages/LoginPage.ts because that is how our old framework was laid out. It compiles, the decorators are on the methods, and the class is exported. Every scenario that uses it still fails as an undefined step.
sdods lint -p demo-shopIs there a fixed folder for this, or a config key that tells the runner where to look?
Accepted answer
The folder is fixed, and support/ is not one of them. Per project the runner globs exactly three things for step definitions: the core step library inside the package, steps/**/*.ts and pages/**/*.ts under the project root. A decorated class anywhere else is never loaded, so the steps it declares do not exist as far as generation is concerned.
projects/demo-shop/
sdods.project.yaml
envs/<env>.yaml
features/<module>/*.feature
pages/*.ts <- page objects, nested as deep as you like
steps/fixtures.ts <- the project test object
steps/auth.tsMove LoginPage.ts to projects/demo-shop/pages/ and lint again. There is no key to add another directory, and that is on purpose — the generated specs have to import from one predictable place.
Adding to that: depth under pages/ is free, the glob is recursive, so pages/checkout/CartPage.ts is fine.
The second half people miss is registration. @Fixture<typeof test>('loginPage') names a fixture, and if steps/fixtures.ts does not declare one with that exact name there is nothing to bind the decorated methods to.
export const test = base.extend<{ loginPage: LoginPage }>({
auth: [auth, { scope: 'worker', option: true }],
loginPage: async ({ pages }, use) => use(pages.get(LoginPage)),
});Wrap commands and output in triple backticks and they will render as a code block.
Checking whether you’re signed in…
Have a different question? Ask it.