Test automation
Cypress
A test runner that executes inside the page itself.
Cypress in practice
A JavaScript test runner that executes inside the browser alongside the application instead of driving it from an outside process. That single architectural choice explains almost everything about the tool: commands queue and retry on their own, the runner displays each step as it happens, and a failure can be paused on and inspected in the exact state that produced it. For a front-end team already living in JavaScript, the distance between writing a component and writing a test for it is unusually short.
Where the client’s own front-end engineers will own the suite long after we have gone, this is frequently the right answer even when it is not the quickest one, because the tooling teaches people to write tests rather than merely allowing it. We use it for component-level coverage inside React codebases, for flows a developer wants to debug interactively while building them, and on projects that arrive with a working suite already in it. Converting healthy coverage to a more fashionable runner is rarely the most valuable thing on anyone’s list.
Navigation across origins was a hard wall for years and is now handled through an explicit command rather than transparently. Any journey that bounces through an external identity provider needs deliberate handling instead of just working.
A second browser tab falls outside the model. Flows that open one have to be reshaped, usually by asserting on the link target rather than following it, which quietly tests something adjacent to what the user does.
Spreading one suite across several machines, or across browsers, depends on the hosted service or on third-party orchestration. That is a budget line to settle before the suite grows long enough to need it.
Because the runner shares a run loop with the application, anything outside the browser (files on disk, a database, a mail server) is reached through a plugin boundary rather than directly.
Safari coverage has trailed. WebKit support exists but has not historically stood on the same footing as Chromium and Firefox, so treat it as a useful check rather than as proof.
FAQ
Cypress questions we hear often
Cypress or Playwright for a new project?
Usually Playwright when we are starting from nothing, because parallel execution, several browser engines and multi-tab journeys all arrive without workarounds. Cypress still wins where the people maintaining the suite are front-end developers who value the interactive runner, or where component testing sits at the centre of the plan. Neither of those decisions is what makes a suite succeed or fail.
We have a large Cypress suite. Should we migrate?
Probably not, and certainly not as a project in its own right. Migration turns working coverage into new code carrying new defects and ships no feature to anybody. Where specific specs hurt because of tab handling or an external redirect, move those and leave the rest alone. A wholesale rewrite is generally easier to sell internally than to defend afterwards.
Does it handle login through an external identity provider?
Yes, with effort. The cross-origin command makes possible what used to be impossible, though the more durable pattern is to authenticate once programmatically and reuse that session, which runs faster and breaks less than driving somebody else’s login screen on every execution. If the provider redesigns its markup, a test that clicks through it inherits their release schedule.
Can we use it for API testing?
It will issue requests and assert on what comes back, which is genuinely handy for arranging state before a browser test runs. As the home of a serious API suite it is the wrong shape, since you are carrying the cost of a browser runner to do work that needs no browser at all. Put contract coverage somewhere built for it.
Contact
Wondering if this is the right tool?
Describe what you are trying to verify and we will tell you which instrument fits, including when the answer is one we do not use.