expect() for BDD assertions in Cypress - Framework Patterns

Framework Mode - expect() for BDD assertions

Folder Structure

    cypress/
    ├── e2e/                  # Test specs using BDD style with expect()
    │   ├── login.cy.js       # Example test file
    │   └── userProfile.cy.js
    ├── support/              # Custom commands and reusable utilities
    │   ├── commands.js       # Custom Cypress commands
    │   └── index.js          # Support file loaded before tests
    ├── fixtures/             # Test data files (JSON)
    │   └── users.json
    cypress.config.js         # Cypress configuration file
    package.json              # Project dependencies and scripts
    

Test Framework Layers

• Test Specs (e2e/): Contains test files where expect() assertions are used in BDD style to verify app behavior.
• Support Layer (support/): Holds reusable commands and setup code to keep tests clean and DRY (Don't Repeat Yourself).
• Fixtures (fixtures/): Stores static test data to feed tests, improving maintainability and readability.
• Configuration (cypress.config.js): Central place to define environment settings, base URLs, and test options.

Configuration Patterns

Use cypress.config.js to manage environments and test settings:

    // cypress.config.js
    import { defineConfig } from 'cypress'

    export default defineConfig({
      e2e: {
        baseUrl: 'https://example.com',
        env: {
          username: 'testuser',
          password: 'password123'
        },
        setupNodeEvents(on, config) {
          // implement node event listeners here
        }
      }
    })
    

Access environment variables in tests with Cypress.env('username').

Use --config-file CLI option to switch between environment configs (e.g., staging, production).

Test Reporting and CI/CD Integration

• Use built-in Cypress test runner for interactive test execution and real-time expect() assertion results.
• Integrate with mochawesome reporter for detailed HTML and JSON reports.
• Configure CI pipelines (GitHub Actions, Jenkins, GitLab CI) to run Cypress tests headlessly and collect reports.
• Fail builds automatically if any expect() assertion fails, ensuring quality gates.

Best Practices for Using expect() in Cypress

1. Write clear and simple assertions using expect() to describe expected outcomes in human-readable form.
2. Use explicit waits or Cypress commands like cy.get() with should() to ensure elements are ready before asserting.
3. Keep assertions focused: one expect() per logical check to make failures easy to diagnose.
4. Use custom messages or comments to explain the purpose of assertions for better test readability.
5. Reuse common assertion logic by creating custom commands or helper functions in support/.

Self Check

Where in this folder structure would you add a new helper function to assert that a user profile page displays the correct username using expect()?

Key Result

Use Cypress test specs with BDD-style expect() assertions organized alongside support utilities and configuration for clear, maintainable tests.

Practice

1. What is the main purpose of using expect() in Cypress tests?

easy

A. To log messages in the console

B. To run the test suite faster

C. To select elements on the page

D. To check if the actual value matches the expected value

Solution

1. Step 1: Understand the role of expect()

   expect() is used to compare actual results with expected results in tests.

2. Step 2: Identify the correct purpose

   It helps verify if the app behaves as expected by checking values.

3. Final Answer:

   To check if the actual value matches the expected value -> Option D

4. Quick Check:

   expect() compares values [OK]

Hint: Remember: expect() checks actual vs expected values [OK]

Common Mistakes:

• Thinking expect() runs tests
• Confusing expect() with element selectors
• Using expect() to log messages

2. Which of the following is the correct syntax to assert that a variable count equals 5 using expect() in Cypress?

easy

A. expect(count).to.equal(5);

B. expect(count).toBe(5);

C. expect(count).equals(5);

D. expect(count).is(5);

Solution

1. Step 1: Recall Cypress BDD assertion syntax

   Cypress uses Chai assertions where to.equal() checks equality.

2. Step 2: Identify the correct syntax

   expect(count).to.equal(5); is the correct way to assert equality.

3. Final Answer:

   expect(count).to.equal(5); -> Option A

4. Quick Check:

   Use to.equal() for equality [OK]

Hint: Use to.equal() for equality checks in Cypress [OK]

Common Mistakes:

• Using toBe() which is Jest syntax
• Using equals() without to
• Using is() which is invalid

3. What will be the result of this Cypress assertion?

const title = 'Welcome';
expect(title).to.have.length(7);

medium

A. Test passes because 'Welcome' has 7 characters

B. Test fails because length is checked incorrectly

C. Syntax error due to wrong method

D. Test passes but length is 6

Solution

1. Step 1: Check the string length

   The string 'Welcome' has exactly 7 characters.

2. Step 2: Understand the assertion

   to.have.length(7) correctly asserts the string length is 7.

3. Final Answer:

   Test passes because 'Welcome' has 7 characters -> Option A

4. Quick Check:

   String length 7 matches assertion [OK]

Hint: Count characters to verify length assertions [OK]

Common Mistakes:

• Assuming length counts words, not characters
• Confusing length with array length
• Using wrong assertion method

4. Identify the error in this Cypress assertion:

expect(user.name).to.equals('Alice');

medium

A. Missing parentheses after user.name

B. Incorrect method name; should be to.equal

C. Should use expect(user).to.equal('Alice')

D. No error; assertion is correct

Solution

1. Step 1: Check the assertion method

   The correct Chai assertion method is to.equal, not to.equals.

2. Step 2: Confirm syntax correctness

   Using to.equals causes a runtime error because it is not defined.

3. Final Answer:

   Incorrect method name; should be to.equal -> Option B

4. Quick Check:

   Use to.equal, not to.equals [OK]

Hint: Remember: method is to.equal, not to.equals [OK]

Common Mistakes:

• Using to.equals instead of to.equal
• Confusing property access syntax
• Assuming expect needs parentheses after property

5. You want to check that an array items contains the string 'apple' using expect(). Which assertion correctly tests this?

hard

A. expect(items).to.equal('apple');

B. expect(items).to.have.length('apple');

C. expect(items).to.include('apple');

D. expect(items).to.contain.length('apple');

Solution

1. Step 1: Understand the goal

   You want to check if 'apple' is inside the array items.

2. Step 2: Choose the correct assertion

   to.include('apple') checks if the array contains that element.

3. Final Answer:

   expect(items).to.include('apple'); -> Option C

4. Quick Check:

   Use to.include() to check array contents [OK]

Hint: Use to.include() to check if array has an item [OK]

Common Mistakes:

• Using to.equal() which checks full equality
• Using length assertions incorrectly
• Combining contain and length wrongly