Length assertions in Cypress - Framework Patterns

Framework Mode - Length assertions

Folder Structure

  cypress/
  ├── e2e/
  │   ├── lengthAssertions.spec.js      # Test files with length assertions
  ├── support/
  │   ├── commands.js                   # Custom commands
  │   └── e2e.js                       # Support file for global setup
  ├── fixtures/
  │   └── example.json                 # Test data
  cypress.config.js                    # Cypress configuration file
  

Test Framework Layers

• Test Layer (cypress/e2e): Contains test files that use length assertions to verify element counts or array lengths.
• Support Layer (cypress/support): Holds reusable commands and global setup to keep tests clean and DRY.
• Fixtures Layer (cypress/fixtures): Stores static test data used in tests.
• Configuration: cypress.config.js manages environment settings, base URLs, and browser options.

Configuration Patterns

Use cypress.config.js to define:

• Base URL: Set the URL of the application under test.
• Environment Variables: Store credentials or environment-specific data using env property.
• Browser Settings: Configure default browser or allow CLI overrides.

Example snippet from 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
      }
    }
  })
  

Test Reporting and CI/CD Integration

• Use built-in Cypress Dashboard or plugins like mochawesome for detailed HTML reports.
• Integrate Cypress tests into CI/CD pipelines (GitHub Actions, Jenkins, GitLab CI) to run tests on every commit.
• Configure test retries and parallelization to improve reliability and speed.
• Store screenshots and videos on test failures for easier debugging.

Best Practices for Length Assertions Framework

• Use clear and descriptive test names to explain what length is being asserted.
• Prefer explicit waits or retries to avoid flaky tests when asserting dynamic element counts.
• Keep selectors stable and semantic to ensure length assertions target the correct elements.
• Reuse common length assertion logic via custom Cypress commands in support/commands.js.
• Separate test data from tests using fixtures for maintainability.

Self Check

Where would you add a new custom command to assert the length of a list of items in this Cypress framework structure?

Key Result

Organize Cypress tests with clear folder layers, config for environments, reusable commands, and robust reporting to handle length assertions reliably.

Practice

1. What does the Cypress command cy.get('.item').should('have.length', 3) check on a webpage?

easy

A. It verifies that the page has 3 different classes including 'item'.

B. It checks that the text length of '.item' elements is 3 characters.

C. It checks that there are exactly 3 elements with class 'item' on the page.

D. It waits for 3 seconds before continuing the test.

Solution

1. Step 1: Understand cy.get() usage

   cy.get('.item') selects all elements with the class 'item' on the page.

2. Step 2: Understand should('have.length', 3) assertion

   This assertion checks that the number of selected elements is exactly 3.

3. Final Answer:

   It checks that there are exactly 3 elements with class 'item' on the page. -> Option C

4. Quick Check:

   Length assertion = count of elements [OK]

Hint: Length assertions check element count, not text length [OK]

Common Mistakes:

• Confusing element count with text length
• Thinking it checks class names count
• Assuming it waits or delays

2. Which of the following is the correct Cypress syntax to assert that a list has exactly 5 items?

easy

A. cy.get('ul li').expect('length', 5)

B. cy.get('ul li').should('length', 5)

C. cy.get('ul li').assert('have.length', 5)

D. cy.get('ul li').should('have.length', 5)

Solution

1. Step 1: Recall correct assertion syntax

   The correct Cypress assertion to check length is should('have.length', number).

2. Step 2: Check each option

   cy.get('ul li').should('length', 5) misses 'have.'; cy.get('ul li').assert('have.length', 5) uses 'assert' which is not Cypress syntax; cy.get('ul li').expect('length', 5) uses 'expect' incorrectly. Only cy.get('ul li').should('have.length', 5) uses correct syntax.

3. Final Answer:

   cy.get('ul li').should('have.length', 5) -> Option D

4. Quick Check:

   Use should('have.length', number) for length checks [OK]

Hint: Use should('have.length', number) for length assertions [OK]

Common Mistakes:

• Omitting 'have.' in assertion
• Using 'assert' or 'expect' incorrectly
• Confusing length with text assertions

3. Consider this Cypress code snippet:

cy.get('.todo-item').should('have.length', 4)
cy.get('.todo-item').eq(0).should('contain.text', 'Buy milk')

What will happen if the page has only 3 elements with class todo-item?

medium

A. The first assertion fails, stopping the test; second assertion is not run.

B. Both assertions pass because the second does not depend on length.

C. The test passes but logs a warning about length mismatch.

D. The second assertion fails but the first passes.

Solution

1. Step 1: Analyze first assertion

   The first assertion expects 4 elements with class 'todo-item'. If only 3 exist, this assertion fails.

2. Step 2: Understand test flow on failure

   When an assertion fails, Cypress stops the test immediately, so the second assertion is not executed.

3. Final Answer:

   The first assertion fails, stopping the test; second assertion is not run. -> Option A

4. Quick Check:

   Failed assertion stops test execution [OK]

Hint: Failed assertions stop test; later checks won't run [OK]

Common Mistakes:

• Assuming all assertions run despite failure
• Thinking warnings allow test to pass
• Confusing element count with content check

4. You wrote this Cypress test:

cy.get('.card').should('have.length', 5)

But the test fails even though the page shows 5 cards. What is the most likely reason?

medium

A. The assertion syntax is wrong; should use 'have.lengthOf' instead.

B. The selector '.card' is incorrect or does not match all cards.

C. Cypress cannot count elements; it only checks visibility.

D. The page needs a manual refresh before running the test.

Solution

1. Step 1: Verify selector correctness

   If the page visually shows 5 cards but the test fails, the selector '.card' might not match all card elements.

2. Step 2: Check assertion syntax and Cypress behavior

   The syntax should('have.length', 5) is correct. Cypress counts elements matching the selector, so counting works. Manual refresh is not needed.

3. Final Answer:

   The selector '.card' is incorrect or does not match all cards. -> Option B

4. Quick Check:

   Selector must match all elements to count correctly [OK]

Hint: Check your selector matches all elements before asserting length [OK]

Common Mistakes:

• Using wrong or incomplete selectors
• Misunderstanding assertion syntax
• Assuming Cypress needs page refresh

5. You want to test a dynamic list where items can be added or removed. Which Cypress code correctly asserts that the list has at least 2 items but no more than 5 items?

hard

A. cy.get('.list-item').should('have.length.gte', 2).and('have.length.lte', 5)

B. cy.get('.list-item').should('have.length', 2, 5)

C. cy.get('.list-item').should('have.length').within(2, 5)

D. cy.get('.list-item').should('have.lengthBetween', 2, 5)

Solution

1. Step 1: Understand Cypress length assertions

   Cypress supports chaining assertions like should('have.length.gte', 2) for "greater than or equal" and should('have.length.lte', 5) for "less than or equal".

2. Step 2: Evaluate each option

   cy.get('.list-item').should('have.length.gte', 2).and('have.length.lte', 5) correctly chains two assertions for minimum and maximum length. Options B, C, and D use invalid or non-existent syntax.

3. Final Answer:

   cy.get('.list-item').should('have.length.gte', 2).and('have.length.lte', 5) -> Option A

4. Quick Check:

   Use chained length.gte and length.lte for range checks [OK]

Hint: Chain should('have.length.gte') and should('have.length.lte') for ranges [OK]

Common Mistakes:

• Using invalid assertion methods
• Trying to pass multiple lengths in one assertion
• Assuming 'lengthBetween' exists