Bird
Raised Fist0
Cypresstesting~15 mins

Parallel execution in Cypress - Build an Automation Script

Choose your learning style10 modes available
Verify login functionality with parallel test execution
Preconditions (3)
Step 1: Open the login page at '/login'
Step 2: Enter 'user1@example.com' in the email input field
Step 3: Enter 'Password1!' in the password input field
Step 4: Click the 'Login' button
Step 5: Verify the URL changes to '/dashboard'
Step 6: Repeat the above steps for 'user2@example.com' with password 'Password2!' and 'user3@example.com' with password 'Password3!' in parallel
✅ Expected Result: All three login tests run in parallel and each user is successfully logged in, verified by the URL '/dashboard'
Automation Requirements - Cypress
Assertions Needed:
Verify URL is '/dashboard' after login
Verify login button is clickable
Verify email and password fields accept input
Best Practices:
Use Cypress commands consistently
Use data-driven testing for multiple users
Configure Cypress to run tests in parallel using CI or Cypress Dashboard
Avoid hardcoded waits; use Cypress built-in retries and assertions
Use semantic selectors (data-cy attributes) for locating elements
Automated Solution
Cypress
/// <reference types="cypress" />

describe('Parallel Login Tests', () => {
  const users = [
    { email: 'user1@example.com', password: 'Password1!' },
    { email: 'user2@example.com', password: 'Password2!' },
    { email: 'user3@example.com', password: 'Password3!' }
  ];

  users.forEach(({ email, password }) => {
    it(`logs in successfully with ${email}`, () => {
      cy.visit('/login');
      cy.get('[data-cy=email-input]').should('be.visible').type(email);
      cy.get('[data-cy=password-input]').should('be.visible').type(password);
      cy.get('[data-cy=login-button]').should('be.enabled').click();
      cy.url().should('include', '/dashboard');
    });
  });
});

This test suite defines three user credentials in an array. For each user, it runs a separate test case that visits the login page, enters the email and password, clicks the login button, and verifies the URL changes to '/dashboard'.

Selectors use data-cy attributes for stability and clarity. Assertions check visibility and enablement before interacting with elements to avoid flaky tests.

Running these tests in parallel is handled by Cypress when configured with the Cypress Dashboard or CI parallelization, so the code is written to support independent test cases that can run concurrently.

Common Mistakes - 3 Pitfalls
Using hardcoded waits like cy.wait(5000) before assertions
{'mistake': "Using CSS selectors that are brittle like '.btn-primary' or element indexes", 'why_bad': 'These selectors can break easily if UI changes, causing tests to fail unnecessarily.', 'correct_approach': 'Use semantic selectors such as data attributes (e.g., data-cy) that are stable and meant for testing.'}
Writing all login tests inside a single it() block
Bonus Challenge

Now add data-driven testing with 3 different user credentials using Cypress fixtures

Show Hint

Practice

(1/5)
1. What is the main benefit of running tests in parallel in Cypress?
easy
A. It reduces the total test execution time by running tests simultaneously.
B. It makes tests run one after another to avoid conflicts.
C. It automatically fixes failing tests during execution.
D. It disables tests that are not needed for the current run.

Solution

  1. Step 1: Understand parallel execution purpose

    Parallel execution means running multiple tests at the same time instead of one by one.
  2. Step 2: Identify the benefit

    Running tests simultaneously saves time by reducing total test duration.
  3. Final Answer:

    It reduces the total test execution time by running tests simultaneously. -> Option A
  4. Quick Check:

    Parallel execution = faster test runs [OK]
Hint: Parallel means tests run together, saving time [OK]
Common Mistakes:
  • Thinking tests run sequentially in parallel mode
  • Assuming parallel fixes test failures automatically
  • Believing parallel disables some tests
2. Which command correctly enables parallel test execution with recording in Cypress?
easy
A. cypress run --parallel --record --key <key>
B. cypress open --parallel --record --key <key>
C. cypress run --record --key <key>
D. cypress run --key <key> --parallel

Solution

  1. Step 1: Recall correct Cypress CLI syntax

    The correct command to run tests in parallel with recording is cypress run --parallel --record --key <key>.
  2. Step 2: Verify required flags and command

    The command must use cypress run (not open), include --parallel for parallelization, and --record --key <key> for recording.
  3. Final Answer:

    cypress run --parallel --record --key <key> -> Option A
  4. Quick Check:

    Correct CLI command = cypress run --parallel --record --key <key> [OK]
Hint: cypress run + --parallel + --record --key [OK]
Common Mistakes:
  • Using 'cypress open' instead of 'cypress run'
  • Omitting the --record flag
  • Omitting the --parallel flag
3. Given the following Cypress command run in parallel mode:
cypress run --parallel --record --key abc123

What is the expected behavior during test execution?
medium
A. Tests run one by one and results are not recorded.
B. Tests run simultaneously across multiple machines and results are recorded in the Dashboard.
C. Tests run only on a single machine without recording.
D. Tests run in parallel but results are saved locally only.

Solution

  1. Step 1: Analyze the command flags

    The command uses --parallel to run tests simultaneously and --record with a --key to save results to Cypress Dashboard.
  2. Step 2: Understand the effect on test execution

    Tests will run on multiple machines or processes at the same time, and results will be uploaded to the Dashboard for viewing.
  3. Final Answer:

    Tests run simultaneously across multiple machines and results are recorded in the Dashboard. -> Option B
  4. Quick Check:

    Parallel + record = simultaneous runs + Dashboard [OK]
Hint: Parallel + record means multiple machines and Dashboard [OK]
Common Mistakes:
  • Assuming tests run sequentially despite --parallel
  • Thinking results are saved only locally
  • Ignoring the effect of --record and --key
4. You tried running Cypress tests in parallel but noticed tests are not splitting across machines. What is the most likely cause?
medium
A. Tests are not independent and share state, preventing parallel splitting.
B. You forgot to install Cypress Dashboard locally.
C. The command used was cypress open --parallel instead of cypress run --parallel.
D. Parallel execution requires tests to be written in JavaScript only.

Solution

  1. Step 1: Understand requirements for parallel splitting

    Tests must be independent (no shared state) to split correctly across machines in parallel execution.
  2. Step 2: Identify the cause of no splitting

    If tests share state or depend on each other, Cypress cannot split them properly, causing all tests to run on one machine.
  3. Final Answer:

    The command used was cypress open --parallel instead of cypress run --parallel. -> Option C
  4. Quick Check:

    Use 'cypress run' for parallel splitting [OK]
Hint: Tests must be independent to split in parallel [OK]
Common Mistakes:
  • Confusing 'cypress open' with 'cypress run' for parallel
  • Thinking Dashboard installation affects splitting
  • Believing language type restricts parallel execution
5. You want to optimize your Cypress test suite using parallel execution but notice flaky failures when tests run simultaneously. What is the best approach to fix this?
hard
A. Run tests sequentially instead of parallel to avoid failures.
B. Disable recording to speed up test runs and reduce flakiness.
C. Increase the number of parallel machines without changing tests.
D. Refactor tests to be fully independent and avoid shared state or global data.

Solution

  1. Step 1: Identify cause of flaky failures in parallel runs

    Flaky failures often happen because tests share state or interfere with each other when run simultaneously.
  2. Step 2: Choose best fix for flaky parallel tests

    Refactoring tests to be independent and avoid shared global data ensures stable parallel execution.
  3. Final Answer:

    Refactor tests to be fully independent and avoid shared state or global data. -> Option D
  4. Quick Check:

    Independent tests fix flaky parallel runs [OK]
Hint: Make tests independent to fix flaky parallel runs [OK]
Common Mistakes:
  • Just increasing machines without fixing tests
  • Disabling recording does not fix flakiness
  • Switching to sequential loses parallel benefits
Recommended

Ready to prove it?

Pass the test and this pattern moves unknown strong while earning +1 Grip toward your certificate.

10 questions~5 mineasy hard