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 have inherited a Cypress suite. Roughly 900 specs, data-cy attributes throughout, about 60 custom commands in cypress/support/commands.js, and a cypress/fixtures folder nobody has audited in two years.
Management has agreed to a migration but not to a rewrite, so I need an order of operations more than I need a philosophy. What does cy.get become, what happens to custom commands, and what do I do with the fixtures and the intercepts?
Accepted answer
I moved a suite of about that size. Here is the mapping that survived contact.
cy.visit('/checkout') becomes this.goto('checkout'), once the path is a named route in sdods.project.yaml.cy.get('[data-cy=submit]') becomes this.page.getByTestId('submit'), provided testIdAttribute: data-cy is set. Keep the attribute; renaming it in the application is a separate project and not this one.cy.contains('Shipped') becomes getByText, or better getByRole('cell', { name: 'Shipped' }).cy.intercept with a fixture becomes the mock step or a recorded HAR file.cypress/fixtures becomes datasets under data/.Order that worked:
sdods analyze <app dir> first. It counts the test-id attribute in the source rather than guessing it, inventories the existing specs and reports how many of your locators are CSS. Cypress specs are inventoried rather than copied, so nothing is imported behind your back.Two modules in, features list is how I reported progress:
sdods features list -p rwa-bank
sdods coverage -p rwa-bank --routes --uncoveredThe trap in a migration this size is porting the 60 custom commands one to one. You end up with 60 steps, of which 12 are used everywhere and the rest are used once each by the spec they were written for.
Port a command only when a feature file needs it, and check for an existing phrasing first. Then after the first few modules:
sdods steps list -p rwa-bank --unusedAnything that comes back is something you carried across for nothing.
Two process notes, since you said order of operations.
Tag as you go, not afterwards. Every scenario needs exactly one layer tag and exactly one suite tag, and lint refuses without them; sdods lint --fix-tags handles the obvious cases from the folder layout, but it cannot decide that a flow is smoke rather than regression.
Keep the old suite running in CI until the module that replaces it is green. A migration where both suites are red for six weeks is a migration that gets cancelled.
Slightly late, but one thing to expect emotionally: the long cy.get(...).parent().contains(...) chains have no direct translation, and people take that badly for about a week.
They are not missing. Those chains exist because there was no stable way to name the element, and naming the element is the thing you are being asked to do now. Every one I unpicked turned into a getByRole with a name, and about a third of them exposed a genuine accessibility gap in the application, which our frontend team was less pleased about than I was.
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.