Skipping and focusing tests (.skip, .only) in Cypress - Deep Dive

Overview - Skipping And Focusing Tests Skip Only

What is it?

Skipping and focusing tests in Cypress means telling the test runner to ignore some tests or run only specific ones. You can skip tests that are not ready or not relevant now, and focus on tests you want to check quickly. This helps save time and effort during testing by running only what matters.

Why it matters

Without skipping or focusing, every test runs every time, which can be slow and inefficient. If a test is broken or incomplete, it can block progress. Skipping and focusing let you control test execution, making debugging faster and improving productivity.

Where it fits

Before learning this, you should know how to write basic Cypress tests with describe and it blocks. After this, you can learn about test retries, hooks, and parallel test execution to optimize your test suite further.

Mental Model

Core Idea

Skipping and focusing tests let you control which tests run, so you can ignore some or run only specific ones during development or debugging.

Think of it like...

It's like choosing which TV shows to watch: you can skip shows you don't want to see now or focus on just one show to watch closely.

┌───────────────┐
│ Test Suite    │
│ ┌───────────┐ │
│ │ Test 1    │ │
│ │ (run)    │ │
│ ├───────────┤ │
│ │ Test 2    │ │
│ │ (skip)   │ │
│ ├───────────┤ │
│ │ Test 3    │ │
│ │ (only)   │ │
│ └───────────┘ │
└───────────────┘

Build-Up - 7 Steps

1

Foundation

Basic Cypress Test Structure

Concept: Learn how Cypress organizes tests using describe and it blocks.

In Cypress, tests are grouped inside describe blocks. Each test case is written inside an it block. For example: describe('My Test Suite', () => { it('does something', () => { // test code here }) })

Result

Tests run in the order they appear, all executed by default.

Understanding the basic test structure is essential before controlling which tests run.

2

Foundation

Running All Tests By Default

Concept: By default, Cypress runs every test in the suite without skipping or focusing.

If you write multiple it blocks, Cypress runs them all: describe('Suite', () => { it('test 1', () => { /* code */ }) it('test 2', () => { /* code */ }) })

Result

Both tests run every time you start Cypress.

Knowing the default behavior helps you appreciate why skipping and focusing are useful.

3

Intermediate

Skipping Tests With .skip

🤔Before reading on: do you think skipped tests run or are ignored? Commit to your answer.

Concept: You can skip tests or suites by adding .skip to it or describe blocks.

To skip a test: it.skip('this test is skipped', () => { // code here }) To skip a whole suite: describe.skip('skipped suite', () => { it('test inside skipped suite', () => {}) })

Result

Skipped tests do not run and are reported as skipped in the test results.

Skipping helps avoid running tests that are broken or not ready, saving time.

4

Intermediate

Focusing Tests With .only

🤔Before reading on: if you mark one test with .only, do other tests run? Commit to your answer.

Concept: You can focus on specific tests or suites by adding .only, running only those marked.

To focus on a test: it.only('only this test runs', () => { // code here }) To focus on a suite: describe.only('only this suite runs', () => { it('test inside', () => {}) })

Result

Only tests or suites marked with .only run; all others are skipped.

Focusing lets you isolate tests for quick debugging without running the full suite.

5

Intermediate

Combining .skip and .only

🤔Before reading on: what happens if you use both .skip and .only in the same suite? Predict the behavior.

Concept: When .only is used anywhere, only those tests run, even if others have .skip. Skipped tests are ignored unless .only overrides.

Example: it.skip('skipped test', () => {}) it.only('focused test', () => {}) Only the focused test runs, skipped test is ignored.

Result

Tests with .only run exclusively; .skip is ignored if .only exists.

Understanding this priority prevents confusion when multiple modifiers are used.

6

Advanced

Impact on Test Reports and CI Pipelines

🤔Before reading on: do skipped tests count as failures in CI? Commit to your answer.

Concept: Skipped tests do not fail but are reported as skipped. Focused tests can hide other failures if left accidentally.

In CI, skipped tests show as skipped, not failed. Using .only accidentally can cause incomplete test runs, hiding bugs. Best practice: remove .only before committing code.

Result

Test reports show skipped tests separately; CI passes if no failures, even if tests are skipped.

Knowing how skipping and focusing affect reports helps maintain test quality and avoid false positives.

7

Expert

Automated Detection of .only in CI

🤔Before reading on: do you think CI systems detect .only and warn? Commit to your answer.

Concept: Advanced setups include scripts to detect .only in test files to prevent accidental commits.

You can add a pre-commit hook or CI step that scans test files for .only and fails the build if found. Example script: if grep -r "\.only" cypress/integration; then echo ".only found! Remove before commit." exit 1 fi

Result

Build fails if .only is present, preventing incomplete test runs in production.

Automating .only detection enforces discipline and prevents costly mistakes in test execution.

Under the Hood

Cypress test runner parses test files and builds a list of tests to run. When it encounters .skip, it marks those tests as skipped and excludes them from execution. When it finds .only, it filters the test list to include only those marked, ignoring others. This filtering happens before tests run, so skipped tests are not executed at all.

Why designed this way?

This design allows developers to quickly control test execution without changing test code structure. It supports fast debugging and iterative development by focusing on relevant tests. Alternatives like commenting out tests are error-prone and less visible in reports.

┌───────────────┐
│ Test Files    │
├───────────────┤
│ it() blocks   │
│ describe()    │
│ modifiers     │
├───────────────┤
│ Parser reads  │
│ .skip/.only   │
├───────────────┤
│ Test List     │
│ filtered by   │
│ modifiers     │
├───────────────┤
│ Runner executes│
│ filtered list │
└───────────────┘

Myth Busters - 4 Common Misconceptions

Quick: Does it.skip run the test code or ignore it completely? Commit to yes or no.

Common Belief: Skipped tests still run but their results are ignored.

Reality: Skipped tests do not run at all; their code is not executed.

Why it matters: Running skipped tests wastes time and can cause side effects, defeating the purpose of skipping.

Quick: If you have multiple it.only tests, do they all run or just one? Commit to your answer.

Common Belief: Only one .only test runs at a time.

Reality: All tests marked with .only run; others are skipped.

Why it matters: Misunderstanding this can cause confusion when multiple focused tests run unexpectedly.

Quick: Does .only override .skip or vice versa? Commit to your answer.

Common Belief: .skip always overrides .only, so skipped tests never run.

Reality: .only overrides .skip; tests with .only run even if others have .skip.

Why it matters: Incorrect assumptions can lead to unexpected test runs or skipped important tests.

Quick: Do skipped tests cause CI pipelines to fail? Commit to yes or no.

Common Belief: Skipped tests cause CI failures because they are incomplete.

Reality: Skipped tests do not cause failures; they are reported separately and do not affect pass/fail status.

Why it matters: Knowing this prevents confusion when tests are skipped but CI passes.

Expert Zone

1

Using .only in nested describe blocks focuses only those inner tests, allowing fine-grained control.

2

Skipping tests can hide flaky tests temporarily, but overuse can mask real problems in the suite.

3

Combining .skip and .only in large suites requires careful management to avoid accidentally skipping critical tests.

When NOT to use

Avoid using .only in committed code or CI environments because it prevents full test coverage. Instead, use test tags or environment variables to control test runs in production.

Production Patterns

Teams use .skip and .only during development and debugging locally, but enforce removal before CI runs. Some use custom scripts or lint rules to detect .only. Others tag tests for selective runs instead of .skip to maintain visibility.

Connections

Feature Flags

Both control what runs or is visible based on conditions.

Understanding skipping tests is like feature flags in software: both enable selective activation to manage complexity and risk.

Project Management Prioritization

Focusing tests parallels prioritizing tasks to focus effort on what matters most.

Knowing how to focus tests helps appreciate prioritization principles in managing work efficiently.

Traffic Light System in Psychology

Skipping and focusing tests resemble red/yellow/green signals controlling flow.

This connection shows how simple signals can manage complex processes by controlling what proceeds or pauses.

Common Pitfalls

#1 Leaving .only in test files committed to version control.

Wrong approach:

it.only('test runs alone', () => {
// test code
})

Correct approach:

it('test runs normally', () => {
// test code
})

Root cause:

Forgetting to remove .only after debugging causes incomplete test runs in CI.

#2 Using .skip to ignore flaky tests permanently.

Wrong approach:

it.skip('flaky test', () => {
// flaky code
})

Correct approach:

it('flaky test', () => {
// fix flaky code or mark as flaky with retries
})

Root cause:

Skipping hides problems instead of fixing them, leading to technical debt.

#3 Assuming skipped tests run but results are ignored.

Wrong approach:

it.skip('test', () => {
cy.visit('/page')
// test steps
})

Correct approach:

// Remove .skip to run test
it('test', () => {
cy.visit('/page')
// test steps
})

Root cause:

Misunderstanding that skipped tests do not execute any code.

Key Takeaways

Skipping and focusing tests control which tests run, improving efficiency during development.

Using .skip prevents tests from running and marks them as skipped in reports without failure.

Using .only runs only the marked tests or suites, ignoring all others.

Accidentally committing .only can cause incomplete test runs and hide failures in CI.

Best practice is to use skipping and focusing locally and remove them before committing code.