Why test structure organizes assertions in Cypress - Automation Benefits in Action

Verify login page elements and successful login

Preconditions (1)

Step 1: Open the login page at 'https://example.com/login'

Step 2: Verify the email input field is visible and enabled

Step 3: Verify the password input field is visible and enabled

Step 4: Verify the login button is visible and enabled

Step 5: Enter '[e-mail]' in the email input field

Step 6: Enter 'Password123!' in the password input field

Step 7: Click the login button

Step 8: Verify the URL changes to 'https://example.com/dashboard'

Step 9: Verify the dashboard heading contains text 'Welcome, User!'

✅ Expected Result: All elements are visible and enabled before interaction. After login, the user is redirected to the dashboard page with a welcome message.

Automation Requirements - Cypress

Assertions Needed:

Check visibility and enabled state of email input

Check visibility and enabled state of password input

Check visibility and enabled state of login button

Check URL after login

Check dashboard welcome text

Best Practices:

Use Cypress commands chaining for clear test flow

Group related assertions logically within the test

Use descriptive test and assertion messages

Avoid redundant assertions by organizing them in a structured way

Use selectors by data attributes for stability

Automated Solution

Cypress

describe('Login Page Test', () => {
  it('should verify login page elements and perform successful login', () => {
    cy.visit('https://example.com/login');

    // Verify input fields and button are visible and enabled
    cy.get('[data-cy=email-input]')
      .should('be.visible')
      .and('be.enabled');

    cy.get('[data-cy=password-input]')
      .should('be.visible')
      .and('be.enabled');

    cy.get('[data-cy=login-button]')
      .should('be.visible')
      .and('be.enabled');

    // Enter credentials
    cy.get('[data-cy=email-input]').type('[e-mail]');
    cy.get('[data-cy=password-input]').type('Password123!');

    // Click login
    cy.get('[data-cy=login-button]').click();

    // Verify URL changed to dashboard
    cy.url().should('eq', 'https://example.com/dashboard');

    // Verify welcome message on dashboard
    cy.get('[data-cy=dashboard-heading]')
      .should('be.visible')
      .and('contain.text', 'Welcome, User!');
  });
});

This test script uses Cypress to automate the manual test case steps.

First, it visits the login page URL.

Then it groups assertions to check that the email input, password input, and login button are all visible and enabled before interacting with them. Grouping these assertions helps keep the test organized and clear.

Next, it types the provided credentials into the input fields and clicks the login button.

After the login action, it asserts that the URL changes to the dashboard page, confirming navigation success.

Finally, it verifies that the dashboard heading contains the expected welcome text.

Selectors use data-cy attributes for stability and clarity.

This structure organizes assertions logically: first verifying page readiness, then performing actions, then verifying results. This approach makes the test easy to read, maintain, and debug.

Common Mistakes - 4 Pitfalls

Not grouping assertions and mixing checks with actions

Using fragile selectors like CSS classes or XPath that change often

Not verifying element visibility and enabled state before interacting

{'mistake': 'Hardcoding URLs without checking navigation properly', 'why_bad': 'May miss navigation failures or partial page loads.', 'correct_approach': "Use Cypress's cy.url() assertion to confirm correct page navigation."}

Bonus Challenge

Now add data-driven testing with 3 different sets of login credentials (valid and invalid) to verify login success and failure messages.

Show Hint

Practice

1. Why do we use describe blocks in Cypress test files?

easy

A. To run tests faster by skipping some tests

B. To group related tests and make the test suite easier to understand

C. To write assertions inside the describe block directly

D. To automatically fix failing tests

Solution

1. Step 1: Understand the purpose of describe blocks

   describe blocks group related tests together, making the test suite organized and easier to read.

2. Step 2: Recognize what describe does not do

   It does not skip tests, fix tests, or contain assertions directly; those go inside it blocks.

3. Final Answer:

   To group related tests and make the test suite easier to understand -> Option B

4. Quick Check:

   Grouping tests = A [OK]

Hint: Remember: describe groups tests, it runs them [OK]

Common Mistakes:

• Thinking assertions go inside describe directly
• Believing describe speeds up test execution
• Confusing describe with test skipping

2. Which of the following is the correct way to write a test with assertions inside Cypress?

easy

A. describe('My Test', () => { it('checks title', () => { cy.title().should('include', 'Home') }) })

B. it('checks title', () => { describe('My Test', () => { cy.title().should('include', 'Home') }) })

C. describe('My Test', () => { cy.title().should('include', 'Home') })

D. cy.title().should('include', 'Home')

Solution

1. Step 1: Identify correct test structure

   The correct structure is describe block containing it block, which contains assertions.

2. Step 2: Check each option

   describe('My Test', () => { it('checks title', () => { cy.title().should('include', 'Home') }) }) follows this pattern. it('checks title', () => { describe('My Test', () => { cy.title().should('include', 'Home') }) }) wrongly nests describe inside it. describe('My Test', () => { cy.title().should('include', 'Home') }) puts assertion directly in describe. cy.title().should('include', 'Home') has no test structure.

3. Final Answer:

   describe with it containing assertions -> Option A

4. Quick Check:

   describe > it > assertions = C [OK]

Hint: Assertions go inside it, not directly in describe [OK]

Common Mistakes:

• Placing assertions directly inside describe
• Nesting describe inside it
• Writing assertions outside any test block

3. Given this Cypress test code, what will be the test result?

describe('Page Tests', () => {
  it('checks header', () => {
    cy.get('h1').should('contain.text', 'Welcome')
  })
  it('checks footer', () => {
    cy.get('footer').should('be.visible')
  })
})

medium

A. Both tests pass if header text is 'Welcome' and footer is visible

B. Only the first test runs because second is outside describe

C. Tests fail because assertions are outside it blocks

D. Tests fail due to syntax error in describe block

Solution

1. Step 1: Analyze test structure

   Both tests are inside the describe block and each assertion is inside its own it block.

2. Step 2: Understand assertion conditions

   If the header contains 'Welcome' and footer is visible, both assertions pass and tests pass.

3. Final Answer:

   Both tests pass if header text is 'Welcome' and footer is visible -> Option A

4. Quick Check:

   Proper structure + correct page content = D [OK]

Hint: Check if assertions are inside it and conditions match page [OK]

Common Mistakes:

• Thinking tests run outside describe
• Confusing assertion placement
• Assuming syntax errors without checking code

4. Identify the error in this Cypress test code:

describe('Login Tests', () => {
  it('checks login button', () => {
    cy.get('#login').should('be.visible')
  })
  it('checks logout button') {
    cy.get('#logout').should('be.visible')
  }
})

medium

A. Incorrect selector syntax for cy.get

B. Using describe inside it block

C. Assertions placed outside it blocks

D. Missing arrow function syntax in second it block

Solution

1. Step 1: Check syntax of it blocks

   The first it block uses arrow function correctly. The second it block is missing the arrow function parentheses and arrow before the block.

2. Step 2: Confirm other parts are correct

   No describe inside it, assertions are inside it, and selectors are valid CSS selectors.

3. Final Answer:

   Missing arrow function syntax in second it block -> Option D

4. Quick Check:

   Arrow function missing = A [OK]

Hint: Check each it has arrow function syntax () => { } [OK]

Common Mistakes:

• Ignoring missing arrow function syntax
• Thinking assertions can be outside it
• Assuming selector syntax error without checking

5. You want to organize tests for a login page with multiple assertions: checking input fields, button visibility, and error messages. Which test structure best organizes these assertions for clarity and easy debugging?

hard

A. Put all assertions inside a single it block without describe

B. Use multiple describe blocks for each assertion inside one it block

C. Use one describe block for the login page, with separate it blocks for inputs, buttons, and errors

D. Write assertions outside any describe or it blocks for faster execution

Solution

1. Step 1: Understand test organization best practices

   Grouping related tests in one describe block and separating different checks into individual it blocks improves clarity and debugging.

2. Step 2: Evaluate options

   Use one describe block for the login page, with separate it blocks for inputs, buttons, and errors follows best practice. Put all assertions inside a single it block without describe mixes all assertions making debugging hard. Use multiple describe blocks for each assertion inside one it block misuses describe inside it. Write assertions outside any describe or it blocks for faster execution breaks test structure and causes errors.

3. Final Answer:

   Use one describe block for the login page, with separate it blocks for inputs, buttons, and errors -> Option C

4. Quick Check:

   Group with describe, separate with it = B [OK]

Hint: Group related tests in describe; separate checks in it blocks [OK]

Common Mistakes:

• Putting all assertions in one it block
• Nesting describe inside it blocks
• Writing assertions outside test blocks