Selenium and Cypress literacy

Most testers do not choose a framework. They inherit one, on their second week, with four hundred tests and nobody left who wrote them.

So the useful skill is literacy rather than preference. Enough to read the suite, judge whether it is worth keeping, and fix what fails without rewriting anything.

Selenium WebDriver is the long-standing standard. It drives a real browser through a driver process, in almost any language, and it is a W3C specification rather than a product.

Cypress runs your test inside the browser alongside the application. That gives excellent developer experience and imposes real architectural limits.

Both are entirely capable of holding a good suite. Both have traps that show up in inherited code.

The terms you will hear

• WebDriver. The W3C protocol Selenium uses to control a browser.
• Explicit wait. Selenium's way of waiting for a condition. Correct, and verbose.
• Implicit wait. A global timeout applied to element lookups. A frequent source of confusion.
• Stale element reference. Selenium's error when the page re-rendered after you found an element.
• Command chain. Cypress's queued, asynchronous command list. Not promises, despite the syntax.
• Retry-ability. Cypress re-running an assertion until it passes or times out.

Selenium, and what goes wrong

Selenium is stable, universal and unopinionated. Nothing is provided for you, so every suite has a homemade layer around it, and the quality of the suite is the quality of that layer.

Three things dominate inherited Selenium code.

• Waits everywhere. Often a global implicit wait plus scattered explicit waits plus a few sleeps, all interacting unpredictably. Untangling this is usually the biggest single flake reduction available.
• Stale element errors. An element found before a re-render, used after. The fix is finding it again at the point of use rather than caching it.
• An unowned wrapper. A BasePage class with two hundred methods that nobody understands. Read it before changing anything, because behaviour hides in there.

Cypress, and what goes wrong

Cypress is pleasant to write and its constraints are architectural rather than incidental.

• The command chain is not promises. cy.get() queues a command. Mixing it with async or await, or using its return value like a value, produces confusing failures. This is the most common misunderstanding in inherited Cypress.
• Same-origin limits. Visiting two different origins in one test is constrained. Suites work around it, and the workaround is often what is failing.
• Retry-ability hides real races. An assertion that eventually passes looks fine. Under load, the product behaviour it tolerated becomes a defect.
• No true multi-tab. Tests that need two sessions get simulated, which is exactly the case that found a real double-spend defect in exploratory testing.

How to judge what you inherited

1. Run it ten times on one commit. You now have a flake rate rather than an opinion, which is the flakiness method.
2. Grep the assertions. Count the weak ones: truthy, defined, not-null, contains-on-a-number. This tells you whether the suite checks anything.
3. Time one diagnosis. Pick a failure and time yourself understanding it. Over twenty minutes means the architecture is against you.
4. Read the shared layer once, properly. An afternoon with the base classes and helpers saves weeks of surprises.
5. Cull before anything else. Duplicates, dead features, cases that have never failed. Usually the fastest improvement available.
6. Then decide. Keep and improve, keep and migrate the critical journeys only, or replace. Migration is a project with a real cost, so scope it deliberately.

A worked assessment

For example, here is one inherited Selenium suite, assessed in a day.

Notice that four of the five steps had nothing to do with the framework. The suite was not bad because it was Selenium. It was bad because nobody had culled it, and the waits were fighting each other.

How to show you know it

• A flake rate and an assertion count for a suite you inherited. It converts "the tests are unreliable" into a diagnosis.
• A cull before a migration. It shows you fix the cheap thing first.
• The command-chain explanation. Being able to explain why mixing await with Cypress commands misbehaves is a reliable literacy signal.
• A migration justified by numbers. Thirty journeys, on evidence, rather than a rewrite on taste.