Test naming conventions in Cypress - Framework Patterns

Framework Mode - Test naming conventions

Folder Structure for Cypress Test Project

  cypress/
  ├── e2e/                  # Test files organized by feature or module
  │   ├── login.cy.js       # Login feature tests
  │   ├── dashboard.cy.js   # Dashboard feature tests
  │   └── userProfile.cy.js # User profile tests
  ├── fixtures/             # Test data files (JSON, etc.)
  │   └── users.json
  ├── support/              # Support files for commands and utilities
  │   ├── commands.js       # Custom Cypress commands
  │   └── index.js          # Support file loaded before tests
  └── plugins/              # Plugins for Cypress
      └── index.js
  cypress.config.js         # Cypress configuration file
  package.json              # Project dependencies and scripts
  

Test Framework Layers in Cypress

• Test Layer (e2e/): Contains test files named clearly to describe the feature and scenario, e.g., login.cy.js.
• Support Layer (support/): Holds reusable commands and utilities to keep tests clean and DRY (Don't Repeat Yourself).
• Fixtures Layer (fixtures/): Stores test data files to separate data from test logic.
• Plugins Layer (plugins/): Extends Cypress functionality if needed.
• Configuration: Central place to set environment variables, base URLs, and browser settings.

Configuration Patterns for Cypress

Use cypress.config.js to manage settings like base URL, test retries, and environment variables.

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

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

Use environment variables for sensitive data and different environments (dev, staging, prod).

Test Reporting and CI/CD Integration

• Integrate Cypress with CI tools like GitHub Actions, Jenkins, or GitLab CI to run tests automatically on code changes.
• Use Cypress Dashboard or plugins like mochawesome for detailed test reports with screenshots and videos.
• Configure reports to show test names clearly, reflecting the naming conventions for easy understanding.

Best Practices for Test Naming Conventions in Cypress

1. Be Descriptive: Test file names and test case names should clearly describe what is tested, e.g., login.cy.js or should display error on invalid password.
2. Use Consistent Format: Use lowercase with dots or camelCase for file names, and write test names in plain English sentences.
3. Group by Feature: Organize tests by feature or module to keep structure clean and easy to navigate.
4. Include Expected Behavior: Test names should state the expected outcome to make reports readable.
5. Avoid Ambiguity: Avoid vague names like test1.cy.js or checkFeature.cy.js.

Self Check Question

Where in this folder structure would you add a new test file for the "Shopping Cart" feature?

Key Result

Organize Cypress tests by feature with clear, descriptive file and test names for easy maintenance and reporting.

Practice

1. Why is it important to use clear and descriptive names in Cypress test cases?

easy

A. Because long names make tests run faster

B. Because clear names help everyone understand what the test does quickly

C. Because unclear names reduce the number of tests needed

D. Because test names affect the browser rendering speed

Solution

1. Step 1: Understand the purpose of test names

   Test names describe what the test checks, so clear names help everyone understand the test purpose quickly.

2. Step 2: Evaluate the options

   Only Because clear names help everyone understand what the test does quickly correctly states the importance of clear names. Options A, C, and D are incorrect because test names do not affect speed or test quantity.

3. Final Answer:

   Because clear names help everyone understand what the test does quickly -> Option B

4. Quick Check:

   Clear descriptive names improve communication [OK]

Hint: Think: Can a friend understand the test name easily? [OK]

Common Mistakes:

• Assuming longer names make tests faster
• Believing test names affect browser performance
• Ignoring the importance of clarity in names

2. Which of the following is the correct syntax to name a test case in Cypress?

easy

A. describe it 'homepage loads' () => { /* test code */ }

B. test it 'homepage loads' { /* test code */ }

C. it('should load the homepage', () => { /* test code */ })

D. it: 'homepage loads' { /* test code */ }

Solution

1. Step 1: Recall Cypress test syntax

   Cypress uses the it function with a string name and a callback function to define a test case.

2. Step 2: Check each option

   it('should load the homepage', () => { /* test code */ }) matches the correct syntax. Options B, C, and D have invalid syntax or misplaced keywords.

3. Final Answer:

   it('should load the homepage', () => { /* test code */ }) -> Option C

4. Quick Check:

   Correct it syntax = it('should load the homepage', () => { /* test code */ }) [OK]

Hint: Remember: it('name', () => {}) is correct syntax [OK]

Common Mistakes:

• Using incorrect keywords like 'test it' or 'describe it'
• Missing parentheses or arrow functions
• Using colons instead of parentheses

3. Given the following Cypress test code, what will be the test name shown in the test report?

describe('Login Page', () => {
  it('accepts valid credentials', () => {
    // test steps
  })
})

medium

A. Login Page accepts valid credentials

B. accepts valid credentials

C. Login Page

D. describe Login Page it accepts valid credentials

Solution

1. Step 1: Understand how Cypress combines test names

   Cypress combines the describe block name and the it test name separated by a space for the full test name.

2. Step 2: Combine the strings

   The describe is 'Login Page' and the it is 'accepts valid credentials', so combined they form 'Login Page accepts valid credentials'.

3. Final Answer:

   Login Page accepts valid credentials -> Option A

4. Quick Check:

   Full test name = describe + it [OK]

Hint: Test name = describe block + it block text [OK]

Common Mistakes:

• Choosing only the it block name
• Choosing only the describe block name
• Including keywords like 'describe' or 'it' in the name

4. Identify the problem in this Cypress test naming and fix it:

describe('User Login')
it('should login successfully', () => {
  // test code
})

medium

A. Missing curly braces {} after describe block

B. The it block name is too long

C. describe should be replaced with test

D. The test code should be inside a function named loginTest

Solution

1. Step 1: Check describe block syntax

   The describe block must have curly braces {} to wrap its content, but here it is missing.

2. Step 2: Fix the syntax

   Add curly braces after describe('User Login') to include the it block inside it.

3. Final Answer:

   Missing curly braces {} after describe block -> Option A

4. Quick Check:

   describe block needs {} [OK]

Hint: Always wrap describe content in curly braces {} [OK]

Common Mistakes:

• Ignoring missing braces causing syntax errors
• Thinking test names length causes errors
• Replacing describe with test incorrectly

5. You want to write Cypress tests for a shopping cart feature. Which test naming approach follows best practices for clarity and organization?

hard

A. describe('Shopping Cart', () => { it('should do stuff') it('should do other stuff') it('should do more stuff') })

B. describe('Cart Tests', () => { it('test1') it('test2') it('test3') })

C. describe('Shopping Cart', () => { it('adds item') it('removes item') it('updates quantity') })

D. describe('Shopping Cart Feature', () => { it('adds item to cart successfully') it('removes item from cart') it('updates item quantity correctly') })

Solution

1. Step 1: Evaluate clarity of describe and it names

   describe('Shopping Cart Feature', () => { it('adds item to cart successfully') it('removes item from cart') it('updates item quantity correctly') }) uses clear, descriptive names for both the describe block and each it test, explaining exactly what each test does.

2. Step 2: Compare with other options

   Options B, C, and D use vague or incomplete test names that do not clearly communicate test purpose.

3. Final Answer:

   describe('Shopping Cart Feature', () => { it('adds item to cart successfully') it('removes item from cart') it('updates item quantity correctly') }) -> Option D

4. Quick Check:

   Clear, descriptive names improve test readability [OK]

Hint: Use full descriptive names in describe and it blocks [OK]

Common Mistakes:

• Using vague test names like 'test1' or 'should do stuff'
• Skipping descriptive details in test names
• Using inconsistent naming styles