What Is Cypress? Architecture, Philosophy and How It Differs from Selenium

📚 QA Engineering 📂 Chapter 53: Cypress Setup and Architecture — Fast, Reliable Front-End Testing 📄 Lesson 53010 Intermediate 🕒 April 8, 2026

Cypress is not just another Selenium alternative — it is a fundamentally different approach to browser testing. While Selenium operates outside the browser by sending commands over the WebDriver protocol, Cypress runs inside the browser alongside your application code. This architectural decision gives Cypress direct access to the DOM, network requests, timers and everything else happening in the browser, making tests faster, more reliable, and easier to debug. Understanding this architecture is essential before writing your first test.

Cypress Architecture — Inside the Browser, Not Outside It

The architectural difference between Cypress and Selenium explains nearly every advantage and limitation of both tools.

// Cypress architecture — how it works under the hood

/*
  ┌──────────────────────────────────────────────────┐
  │  BROWSER (Chrome / Firefox / Edge / Electron)    │
  │                                                  │
  │  ┌────────────────────┐ ┌─────────────────────┐  │
  │  │  Your Application  │ │  Cypress Test Code   │  │
  │  │  (the app under    │ │  (runs in the SAME   │  │
  │  │   test, loaded in  │ │   browser context)   │  │
  │  │   an iframe)       │ │                      │  │
  │  └────────────────────┘ └─────────────────────┘  │
  │                                                  │
  │  ┌──────────────────────────────────────────────┐│
  │  │  Cypress Driver (orchestrates commands,      ││
  │  │  manages retries, captures snapshots)        ││
  │  └──────────────────────────────────────────────┘│
  └──────────────────────────────────────────────────┘
                        │
                  Node.js Server
              (file system, network
               proxying, plugins)

  SELENIUM COMPARISON:
  Test Code → HTTP → WebDriver → Browser
  (outside)   (slow)  (bridge)   (isolated)

  CYPRESS:
  Test Code → Direct DOM Access → Browser
  (inside)    (instant)           (same process)
*/

// Key architectural advantages
const CYPRESS_ADVANTAGES = {
  "Automatic waiting": `Cypress automatically retries commands until the element
    is found or the timeout expires — no explicit waits needed. When you write
    cy.get('.btn').click(), Cypress retries .get() for up to 4 seconds by default.`,

  "Real-time reloading": `The Test Runner watches your test files and re-runs
    automatically when you save changes — instant feedback during development.`,

  "Time-travel debugging": `Every command takes a DOM snapshot. You can hover over
    any step in the Command Log to see exactly what the page looked like at that
    moment — including before and after states.`,

  "Network control": `Cypress can intercept, stub, and modify HTTP requests and
    responses without external tools — cy.intercept() replaces the need for
    mock servers in many scenarios.`,

  "Consistent results": `Because Cypress controls the test loop synchronously
    inside the browser, there are no race conditions between the test and the
    application. Commands execute in a deterministic order.`,
};

// Key architectural limitations
const CYPRESS_LIMITATIONS = {
  "Single browser tab": `Cypress cannot open or switch between multiple browser
    tabs or windows. Multi-tab workflows must be tested differently.`,

  "Same-origin only": `Cypress can only visit URLs on the same origin within a
    single test. Cross-origin navigation requires cy.origin() (Cypress 12+).`,

  "JavaScript/TypeScript only": `Tests must be written in JavaScript or TypeScript.
    No Python, Java, or C# support.`,

  "Limited browser support": `Chrome, Firefox, Edge, and Electron. No Safari
    support (WebKit not available in Cypress).`,

  "No native mobile testing": `Cypress tests responsive layouts via viewport
    resizing but cannot test native mobile apps.`,
};

console.log("Cypress Architecture: Inside the browser");
console.log("Selenium Architecture: Outside the browser via WebDriver protocol");

Note: The fact that Cypress runs inside the browser is what enables its automatic retry mechanism. When you write cy.get('.product-card'), Cypress does not make a single attempt and fail — it continuously polls the DOM for up to 4 seconds (configurable), checking every few milliseconds until the element appears. This built-in retry eliminates the need for explicit WebDriverWait calls that Selenium requires for every interaction. Most Selenium flakiness comes from missing or incorrect waits; Cypress avoids this entire category of bugs by design.

Tip: Cypress’s inability to handle multiple tabs is often cited as a limitation, but it rarely matters in practice. Most multi-tab workflows can be tested by verifying the href and target attributes of links rather than clicking them and switching tabs: cy.get('a.terms-link').should('have.attr', 'href', '/terms').and('have.attr', 'target', '_blank'). This verifies the link will open in a new tab without needing to actually open one.

Warning: Cypress is JavaScript/TypeScript only. If your QA team exclusively uses Python or Java, adopting Cypress means learning a new language — or choosing Selenium or Playwright (which support both). This is not a minor consideration: the team’s existing language expertise directly impacts adoption speed, code quality, and long-term maintenance. Evaluate language fit before committing to a tool.

Common Mistakes

Mistake 1 — Treating Cypress like Selenium and adding explicit waits everywhere

❌ Wrong: cy.wait(5000); cy.get('.btn').click(); — adding fixed waits like Selenium’s time.sleep().

✅ Correct: cy.get('.btn').click(); — Cypress automatically retries .get() until the element appears or the default timeout (4s) expires. No manual wait needed.

Mistake 2 — Choosing Cypress without evaluating browser coverage needs

❌ Wrong: “Cypress is the best testing tool — we will use it for everything.” Then discovering it does not support Safari, which 20% of users rely on.

✅ Correct: “Cypress is excellent for Chrome/Firefox/Edge E2E testing. For Safari/WebKit coverage, we will supplement with Playwright’s WebKit support or a cloud provider.”

🧠 Test Yourself

What is the fundamental architectural difference between Cypress and Selenium?

Cypress uses a faster version of the WebDriver protocol to communicate with browsers.
Cypress runs inside the browser in the same process as the application under test, giving it direct access to the DOM, network layer, and JavaScript runtime. Selenium runs outside the browser and communicates via the W3C WebDriver protocol over HTTP. This architectural difference is why Cypress has automatic retries, time-travel debugging, and network interception built in — it has direct access to everything happening in the browser. It also explains Cypress’s limitations: it cannot control multiple tabs or test across origins easily because it is bound to a single browser context.
Cypress runs tests in a headless-only mode that is faster than Selenium’s headed execution.
Cypress uses artificial intelligence to automatically find elements instead of manual locators.

Cypress Architecture — Inside the Browser, Not Outside It #

Common Mistakes #

Mistake 1 — Treating Cypress like Selenium and adding explicit waits everywhere #

Mistake 2 — Choosing Cypress without evaluating browser coverage needs #

🧠 Test Yourself #

📚 More in this Tutorial Series

Cypress Architecture — Inside the Browser, Not Outside It

Common Mistakes

Mistake 1 — Treating Cypress like Selenium and adding explicit waits everywhere

Mistake 2 — Choosing Cypress without evaluating browser coverage needs

🧠 Test Yourself