Our hierarchy is BasePage to AuthenticatedPage to DashboardPage to ReportsPage, and there is talk of a fifth level for the two report variants.
Nobody can say where a locator lives without opening four files. Is there a recommended depth, and does the folder layout under pages/ matter to the runner at all?
Accepted answer
Recommended depth is one: your class extends BasePage and stops.
Everything you are using inheritance for is better done with composition. A component class held as a field gives you the same reuse without the "where is this locator actually defined" problem, and it composes in more than one direction — a header can appear on pages that have nothing else in common.
AuthenticatedPage in particular is usually a smell. Being signed in is not a property of a page, it is a property of the scenario, and the scenario says it with @user:standard and the cached storage state that comes with it.
One class per meaningful surface. When two surfaces share three locators, extract a component, not a superclass.
On the folder question: it does not matter. The glob is pages/**/*.ts, so organise the directory however reads best — by module is what most projects settle on. Folder depth is free; class depth is not.
Keep the decorated steps on the class you register as a fixture. Spreading step decorators across a class hierarchy makes it much harder to answer the only question that matters when generation fails, which is which fixture a given step is bound to.
We arrived here with a five-deep hierarchy ported straight out of a Selenium suite and flattened it over a couple of months. Nothing was lost. Two of the intermediate classes turned out to hold one method each, and one held only waits that were no longer needed.
The flattening pass is also a good moment to notice which locators nobody references any more.
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