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.
Reviewing a colleague's proposal and we disagreed twice in one file, so I would like a rule rather than a preference.
They wrote When I add the extended warranty to the basket as a project step, and When I click the row action "Delete" also as a project step. The second one feels like something every project would want. Where is the line?
The line I use: a shared step is true of any web application. Navigate to a route, click a control by role and name, fill a field by its label, send a request, assert a status. None of them know what your product sells.
Anything that names your domain belongs to the project, and it belongs on a page-object method rather than in a loose steps file, because the awkward locator and the step text want to live together. So the warranty one is right where it is.
The row action one is a shared step wearing a project hat. It already exists, more or less:
When I click the "Delete" button
When I click the element with test id "row-delete"Before writing either, look:
sdods steps list -p demo-shop --grep rowThere is also a practical constraint. The shared library ships inside the core package and is globbed from there, so you cannot add to it from a project even if you want to. A genuinely generic phrasing has to go upstream; until it does, a project step in the same phrasing style is the correct thing to write.
Worth running periodically on any project older than a few months:
sdods steps list -p demo-shop --unusedSteps nobody calls are the tell that the vocabulary drifted.
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.