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.
Clean lint, then the run dies immediately on a step nobody wrote. Turning the flag on finds it:
sdods lint -p shop --undefined-steps✖ features/checkout/payment.feature:14 steps/undefined Undefined step: Given I am on the checkout page
1 feature file(s), 1 error(s), 0 warning(s)If it can find it, why is it not on by default? Feels like the most valuable check of the lot.
Accepted answer
Cost. Every other rule is a parse of the feature files and some string comparison against your project yaml — milliseconds, no build. Finding undefined steps means actually generating the specs and letting the generator report what it could not bind, which is the slow part of a run happening before the run.
On a small project the difference is not worth arguing about. On a large one it turns lint from something you can put in a file-save hook into something you wait for, and a check people stop running is worth less than a slower check that runs.
The compromise most teams land on: bare sdods lint in the editor loop and the pre-commit hook, --undefined-steps in CI where the wait is somebody else's.
Also worth saying it is not the only safety net — a run generates specs too, so an undefined step always fails, just later and with a worse message. The flag buys you the failure at lint time with a file and a line number instead of mid-run.
Before you add a new step, check whether the phrasing already exists:
sdods steps list -p shop --grep "checkout page"Most undefined steps we hit turned out to be a near-miss of a step already in the catalogue — "I am on the checkout page" against "I navigate to the checkout page". Reusing the existing phrasing is better than writing a second step that does the same thing.
Worth knowing the opposite direction is a separate command rather than a lint rule. Steps nobody calls do not stop anything, so they are not part of this:
sdods steps list -p shop --unusedDifferent risks, which is why they are split. A feature referring to a step that does not exist cannot run at all; a step definition nobody calls is dead code you clean up when you feel like it.
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.