← All questions

Inherited 900 Cypress specs: what maps to what, and what happens to custom commands?

4 answers

• 57votes✓

  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' }).
  • Custom commands split three ways: some already exist in the shared step library, some become decorated page-object methods, and a surprising number turn out to be dead.
  • cy.intercept with a fixture becomes the mock step or a recorded HAR file.
  • cypress/fixtures becomes datasets under data/.

  Order that worked:

  1. 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.
  2. Apply the proposal, fix the two or three guesses it could not make — base URLs are the usual one — and get the generated health features green.
  3. Migrate one module at a time, and do not start with the biggest.
  4. Run coverage after each module so the remaining work is a number rather than a feeling.

  Two modules in, features list is how I reported progress:

  

  bashCopy

  sdods features list -p rwa-bank
  sdods coverage -p rwa-bank --routes --uncovered

  Migrating from Playwright, Cypress and Cucumber

  CPanswered by Chandra Pillai873 · 13 Sept 2023
• 24votes

  The 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:

  bashCopy

  sdods steps list -p rwa-bank --unused

  Anything that comes back is something you carried across for nothing.

  RGanswered by Rafa Garrido12,996 · 13 Sept 2023
• 18votes

  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.

  PVanswered by Priya Venkateshmaintainer29,604 · 14 Sept 2023
• 8votes

  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.

  TVanswered by Thom Vasseur5,470 · 2 Oct 2023