Why assertions verify expected behavior in Cypress - Framework Benefits

Framework Mode - Why assertions verify expected behavior

Folder Structure of a Cypress Test Project

  cypress/
  ├── e2e/                # Test files with assertions
  │   └── login.spec.js
  ├── fixtures/           # Test data files (JSON)
  │   └── users.json
  ├── support/            # Custom commands and utilities
  │   ├── commands.js
  │   └── e2e.js
  cypress.config.js       # Cypress configuration file
  package.json            # Project dependencies and scripts
  

Test Framework Layers in Cypress

• Test Layer (e2e/): Contains test scripts where assertions verify expected behavior, e.g., checking if a button is visible or a URL is correct.
• Support Layer (support/): Holds reusable commands and helper functions to keep tests clean and DRY (Don't Repeat Yourself).
• Fixtures Layer (fixtures/): Stores static test data like user credentials or sample inputs.
• Configuration (cypress.config.js): Defines environment settings like base URL, browser options, and timeouts.

Configuration Patterns in Cypress

Use cypress.config.js to set base URLs and environment variables for different environments (dev, staging, prod).

  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').

Test Reporting and CI/CD Integration

Cypress supports built-in test reports showing passed and failed assertions.

Integrate with CI/CD tools (GitHub Actions, Jenkins) to run tests automatically on code changes.

Use reporters like mochawesome for detailed HTML reports.

  # Example GitHub Actions snippet
  name: Cypress Tests
  on: [push]
  jobs:
    test:
      runs-on: ubuntu-latest
      steps:
        - uses: actions/checkout@v3
        - uses: cypress-io/github-action@v5
          with:
            start: npm start
            wait-on: 'http://localhost:3000'
            wait-on-timeout: 60
  

Best Practices for Assertions in Cypress

• Clear Expected Behavior: Write assertions that clearly state what the app should do, like should('be.visible') or should('contain.text', 'Welcome').
• Use Explicit Assertions: Avoid vague checks; assert exact values or states to catch bugs early.
• Keep Tests Independent: Each test should verify its own expected behavior without relying on others.
• Use Custom Commands: Encapsulate common assertions in commands to keep tests readable.
• Fail Fast: Assertions help tests fail immediately when behavior is wrong, saving debugging time.

Self-Check Question

Where in this Cypress framework structure would you add a new assertion to verify the login button is visible?

Key Result

Assertions in Cypress tests verify expected behavior by checking actual app states against expected outcomes in test scripts.

Practice

1. Why do we use assertions in Cypress tests?

easy

A. To change the app's data

B. To slow down the test execution

C. To skip parts of the test

D. To check if the app behaves as expected

Solution

1. Step 1: Understand the purpose of assertions

   Assertions are used to verify that the application behaves as expected during tests.

2. Step 2: Identify the correct purpose in options

   Only To check if the app behaves as expected states that assertions check expected behavior, which is correct.

3. Final Answer:

   To check if the app behaves as expected -> Option D

4. Quick Check:

   Assertions verify expected behavior = C [OK]

Hint: Assertions confirm expected results, not change behavior [OK]

Common Mistakes:

• Thinking assertions change app data
• Believing assertions slow tests down
• Confusing assertions with test flow control

2. Which of the following is the correct syntax to assert that a button with id submit is visible in Cypress?

easy

A. cy.get('submit').should('visible')

B. cy.find('#submit').assert('visible')

C. cy.get('#submit').should('be.visible')

D. cy.get('#submit').check('visible')

Solution

1. Step 1: Recall correct Cypress assertion syntax

   In Cypress, cy.get(selector).should('be.visible') checks visibility.

2. Step 2: Compare options with correct syntax

   cy.get('#submit').should('be.visible') matches the correct syntax exactly; others have wrong methods or missing quotes.

3. Final Answer:

   cy.get('#submit').should('be.visible') -> Option C

4. Quick Check:

   Correct assertion syntax = B [OK]

Hint: Use cy.get() with .should('be.visible') for visibility checks [OK]

Common Mistakes:

• Missing '#' for id selector
• Using wrong assertion method like check or assert
• Omitting quotes around assertion string

3. What will happen when this Cypress code runs?

cy.get('.message').should('contain.text', 'Success')

medium

A. Test passes if element with class 'message' contains text 'Success'

B. Test fails if element with class 'message' contains text 'Success'

C. Test passes regardless of element text

D. Test throws a syntax error

Solution

1. Step 1: Analyze the assertion syntax

   The code uses .should('contain.text', 'Success'), which is a valid Cypress assertion chainer.

2. Step 2: Determine test outcome

   The test passes if the element with class 'message' contains the text 'Success'; otherwise, it fails.

3. Final Answer:

   Test passes if element with class 'message' contains text 'Success' -> Option A

4. Quick Check:

   Valid 'contain.text' assertion = A [OK]

Hint: 'contain.text' is valid in Cypress for text content check [OK]

Common Mistakes:

• Thinking 'contain.text' is invalid
• Predicting pass/fail based on text presence
• Confusing with other assertion methods

4. Identify the error in this Cypress assertion:

cy.get('.title').should('have.text', Success)

medium

A. Missing quotes around 'Success' string

B. Wrong selector syntax

C. Incorrect assertion method 'have.text'

D. No error, code is correct

Solution

1. Step 1: Check the assertion syntax

   The text 'Success' must be a string, so it needs quotes around it.

2. Step 2: Identify the error in the code

   The code misses quotes around Success, causing a syntax error or undefined variable.

3. Final Answer:

   Missing quotes around 'Success' string -> Option A

4. Quick Check:

   String literals need quotes = A [OK]

Hint: Always put quotes around text in assertions [OK]

Common Mistakes:

• Forgetting quotes around string values
• Thinking selector syntax is wrong
• Misunderstanding assertion method names

5. You want to verify a checkbox with id agree is checked after clicking it. Which assertion correctly verifies this expected behavior?

hard

A. cy.get('#agree').click().should('have.value', 'checked')

B. cy.get('#agree').click().should('be.checked')

C. cy.get('#agree').click().should('contain.text', 'checked')

D. cy.get('#agree').click().should('be.visible')

Solution

1. Step 1: Understand the goal of the assertion

   We want to confirm the checkbox is checked after clicking it.

2. Step 2: Identify the correct assertion method

   The correct assertion is should('be.checked') which verifies checkbox state.

3. Step 3: Evaluate options

   cy.get('#agree').click().should('be.checked') uses be.checked, which is correct. The other options incorrectly check value, visibility, or text content.

4. Final Answer:

   cy.get('#agree').click().should('be.checked') -> Option B

5. Quick Check:

   should('be.checked') = D [OK]

Hint: Use .should('be.checked') to confirm checkbox is selected [OK]

Common Mistakes:

• Checking visibility instead of checked state
• Looking for text 'checked' inside checkbox
• Using value instead of checked property