First Cypress test - Framework Patterns

Framework Mode - First Cypress test

Folder Structure

  cypress/
  ├── e2e/                  # Test files go here
  │   └── example.cy.js     # Your first test file
  ├── fixtures/             # Test data files (JSON, etc.)
  ├── support/              # Custom commands and reusable code
  │   ├── commands.js       # Custom Cypress commands
  │   └── e2e.js            # Support file loaded before tests
  cypress.config.js         # Cypress configuration file
  package.json              # Project dependencies and scripts
  

Test Framework Layers

• Test Layer (cypress/e2e): Contains test scripts that describe user actions and assertions.
• Support Layer (cypress/support): Holds reusable commands and setup code to keep tests clean.
• Fixtures Layer (cypress/fixtures): Stores static test data like JSON files for data-driven tests.
• Configuration (cypress.config.js): Defines environment settings, base URLs, and test options.

Configuration Patterns

Use cypress.config.js to set base URL, test retries, and browser options.

Manage environments by defining env variables inside the config or via CLI.

Store sensitive data like credentials in environment variables or cypress.env.json (excluded from version control).

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

  export default defineConfig({
    e2e: {
      baseUrl: 'https://example.com',
      supportFile: 'cypress/support/e2e.js',
      env: {
        username: 'testuser',
        password: 'secret'
      },
      retries: 1
    }
  })
  

Test Reporting and CI/CD Integration

Cypress generates detailed test reports in the terminal and browser.

Use plugins like mochawesome for HTML reports.

Integrate Cypress tests in CI/CD pipelines (GitHub Actions, Jenkins) by running npx cypress run.

Fail builds automatically if tests fail, ensuring quality before deployment.

Best Practices

• Keep tests independent and repeatable; avoid relying on previous test state.
• Use cypress/support/commands.js to create reusable custom commands.
• Use fixtures for test data to separate data from test logic.
• Use explicit assertions to verify expected outcomes clearly.
• Run tests in headless mode in CI for faster feedback.

Self Check

Where in this folder structure would you add a new test file for a login feature?

Answer: Add the new test file inside the cypress/e2e/ folder, for example cypress/e2e/login.cy.js.

Key Result

Organize Cypress tests with clear folders for tests, support code, fixtures, and config for maintainable automation.

Practice

1. What is the main purpose of the cy.visit() command in a Cypress test?

easy

A. To run the test suite

B. To check if an element is visible

C. To open a webpage in the test browser

D. To write test descriptions

Solution

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

   The cy.visit() command is used to open a webpage URL in the Cypress test browser.

2. Step 2: Compare with other options

   Options A, B, and C describe other actions unrelated to opening a webpage.

3. Final Answer:

   To open a webpage in the test browser -> Option C

4. Quick Check:

   cy.visit() opens page [OK]

Hint: Remember: visit means open page URL [OK]

Common Mistakes:

• Confusing cy.visit() with assertions
• Thinking it runs tests instead of opening pages
• Mixing it with test description blocks

2. Which of the following is the correct syntax to start a Cypress test block?

easy

A. function test() { describe('Test name') }

B. describe('Test name', () => { it('does something', () => { }) })

C. test('Test name', () => { })

D. run('Test name', () => { })

Solution

1. Step 1: Identify correct Cypress test structure

   Cypress tests use describe blocks to group tests and it blocks for individual tests, both with arrow functions.

2. Step 2: Check syntax correctness

   describe('Test name', () => { it('does something', () => { }) }) correctly shows describe with an it inside using arrow functions. Others use invalid or unsupported syntax.

3. Final Answer:

   describe('Test name', () => { it('does something', () => { }) }) -> Option B

4. Quick Check:

   Use describe and it blocks [OK]

Hint: Tests start with describe and it blocks [OK]

Common Mistakes:

• Using non-Cypress functions like test() or run()
• Missing arrow functions or braces
• Incorrect nesting of blocks

3. Given the following Cypress test code, what will be the test result if the element with id #welcome is visible?

describe('Visibility test', () => {
  it('checks welcome message', () => {
    cy.visit('https://example.com')
    cy.get('#welcome').should('be.visible')
  })
})

medium

A. Test fails because cy.visit() is missing

B. Test passes even if the element is not visible

C. Test fails because should is used incorrectly

D. Test passes because the element is visible

Solution

1. Step 1: Analyze test steps

   The test visits the page, then checks if the element with id #welcome is visible using should('be.visible').

2. Step 2: Understand assertion behavior

   If the element is visible, the assertion passes and so does the test. The code syntax is correct and cy.visit() is present.

3. Final Answer:

   Test passes because the element is visible -> Option D

4. Quick Check:

   Visible element means test passes [OK]

Hint: Visible element + should('be.visible') = pass [OK]

Common Mistakes:

• Assuming test fails without cy.visit()
• Thinking should is wrong syntax
• Ignoring element visibility status

4. Identify the error in this Cypress test code:

describe('My Test', () => {
  it('opens page', () => {
    cy.visit('https://example.com')
    cy.get('.button').should('visible')
  })
})

medium

A. Incorrect assertion keyword, should be should('be.visible')

B. Missing parentheses in should('visible')

C. Wrong selector syntax for class

D. Missing it block inside describe

Solution

1. Step 1: Check assertion syntax

   The assertion should('visible') is incorrect. The correct form is should('be.visible') to check visibility.

2. Step 2: Verify other parts

   The selector .button is correct for class, and it block is present. So only the assertion keyword is wrong.

3. Final Answer:

   Incorrect assertion keyword, should be should('be.visible') -> Option A

4. Quick Check:

   Use should('be.visible') for visibility [OK]

Hint: Use exact assertion keywords like 'be.visible' [OK]

Common Mistakes:

• Using 'visible' instead of 'be.visible'
• Confusing selector syntax for classes
• Omitting it block inside describe

5. You want to write a Cypress test that visits https://example.com, clicks a button with class .submit-btn, and then checks if a success message with id #success-msg is visible. Which of the following test codes correctly implements this?

hard

A. describe('Submit test', () => {
it('clicks and checks success', () => {
cy.visit('https://example.com')
cy.get('.submit-btn').click()
cy.get('#success-msg').should('be.visible')
})
})

B. describe('Submit test', () => {
it('clicks and checks success', () => {
cy.visit('https://example.com')
cy.get('#submit-btn').click()
cy.get('.success-msg').should('visible')
})
})

C. describe('Submit test', () => {
it('clicks and checks success', () => {
cy.visit('https://example.com')
cy.click('.submit-btn')
cy.get('#success-msg').should('be.visible')
})
})

D. describe('Submit test', () => {
it('clicks and checks success', () => {
cy.visit('https://example.com')
cy.get('.submit-btn').click()
cy.get('#success-msg').should('visible')
})
})

Solution

1. Step 1: Verify selectors and commands

   describe('Submit test', () => { it('clicks and checks success', () => { cy.visit('https://example.com') cy.get('.submit-btn').click() cy.get('#success-msg').should('be.visible') }) }) uses correct selectors: .submit-btn for class and #success-msg for id. It uses cy.get().click() correctly.

2. Step 2: Check assertion syntax

   The code uses should('be.visible'), which is the correct assertion for visibility. Other options have wrong selectors or incorrect assertion keywords.

3. Final Answer:

   describe('Submit test', () => { it('clicks and checks success', () => { cy.visit('https://example.com') cy.get('.submit-btn').click() cy.get('#success-msg').should('be.visible') }) }) -> Option A

4. Quick Check:

   Correct selectors + click + should('be.visible') [OK]

Hint: Use correct selectors and should('be.visible') for checks [OK]

Common Mistakes:

• Mixing class and id selectors
• Using cy.click() instead of cy.get().click()
• Wrong assertion keyword 'visible' instead of 'be.visible'