Why DOM interaction handles complex UIs in Cypress - Automation Benefits in Action

Verify interaction with a complex UI element using DOM selectors

Preconditions (2)

Step 1: Locate the main dropdown menu using a data-cy attribute

Step 2: Click the main dropdown to expand it

Step 3: Locate a nested submenu item using a CSS selector

Step 4: Click the nested submenu item

Step 5: Verify that the nested submenu item triggers the expected action (e.g., displays a message or navigates)

✅ Expected Result: The nested submenu item is clicked successfully and the expected action occurs, demonstrating DOM interaction handles complex UI elements

Automation Requirements - Cypress

Assertions Needed:

Verify the main dropdown is visible before clicking

Verify the nested submenu item is visible before clicking

Verify the expected action after clicking the nested submenu item

Best Practices:

Use data-cy attributes for stable selectors

Use cy.get() with explicit assertions for visibility

Avoid brittle XPath selectors

Use Cypress commands chaining for readability

Use beforeEach hook to set up preconditions if needed

Automated Solution

Cypress

describe('Complex UI DOM Interaction Test', () => {
  beforeEach(() => {
    cy.visit('/complex-ui-page')
  })

  it('should interact with nested dropdown menu and verify action', () => {
    // Locate main dropdown using data-cy attribute and verify visibility
    cy.get('[data-cy=main-dropdown]').should('be.visible').click()

    // Locate nested submenu item and verify visibility
    cy.get('.submenu-item.nested').should('be.visible').click()

    // Verify expected action: for example, a message appears
    cy.get('[data-cy=action-message]').should('contain.text', 'Action successful')
  })
})

The test starts by visiting the page with the complex UI.

We use cy.get('[data-cy=main-dropdown]') to select the main dropdown menu. Using data-cy attributes ensures selectors are stable and not affected by styling or layout changes.

We assert the dropdown is visible before clicking to avoid errors.

Next, we select the nested submenu item with a CSS class selector .submenu-item.nested and assert it is visible before clicking.

Finally, we verify the expected action by checking that a message with data-cy=action-message contains the text 'Action successful'.

This approach shows how interacting with DOM elements directly allows us to handle complex UI components reliably.

Common Mistakes - 3 Pitfalls

Using brittle XPath selectors for nested elements

{'mistake': 'Not asserting element visibility before clicking', 'why_bad': 'Clicking invisible or non-existent elements causes test failures and unreliable results', 'correct_approach': "Always use assertions like .should('be.visible') before interacting with elements"}

Hardcoding waits or using cy.wait() instead of checking element state

Bonus Challenge

Now add data-driven testing with 3 different nested submenu items and verify their respective actions

Show Hint

Practice

1. Why is DOM interaction important when testing complex user interfaces with Cypress?

easy

A. It allows tests to directly control and check webpage elements as they change.

B. It makes tests run faster by skipping element checks.

C. It automatically fixes UI bugs during testing.

D. It prevents any changes in the webpage during tests.

Solution

1. Step 1: Understand DOM interaction role

   DOM interaction lets tests access and manipulate webpage elements directly, which is essential for dynamic UIs.

2. Step 2: Connect to complex UI needs

   Complex UIs change after user actions, so direct control helps tests verify these changes accurately.

3. Final Answer:

   It allows tests to directly control and check webpage elements as they change. -> Option A

4. Quick Check:

   DOM interaction = direct control and checking [OK]

Hint: Remember: DOM interaction means direct element control [OK]

Common Mistakes:

• Thinking DOM interaction speeds tests by skipping checks
• Believing it fixes bugs automatically
• Assuming it stops webpage changes during tests

2. Which Cypress command is used to select an element from the DOM for interaction?

easy

A. click()

B. get()

C. should()

D. visit()

Solution

1. Step 1: Identify command purpose

   The get() command selects elements from the DOM to interact with.

2. Step 2: Differentiate from other commands

   click() triggers clicks, should() asserts conditions, and visit() loads pages.

3. Final Answer:

   get() -> Option B

4. Quick Check:

   Element selection = get() [OK]

Hint: Use get() to pick elements before actions [OK]

Common Mistakes:

• Using click() to select elements
• Confusing should() with element selection
• Thinking visit() selects elements

3. Given the code:

cy.get('.btn').click().should('have.class', 'active')

What does this test check in a complex UI?

medium

A. The button with class 'btn' is clicked and then has class 'active'.

B. The button is clicked but should not have class 'active'.

C. The button is selected but not clicked.

D. The button is checked for visibility only.

Solution

1. Step 1: Analyze command chain

   cy.get('.btn') selects the button, click() clicks it, and should('have.class', 'active') asserts it has the 'active' class.

2. Step 2: Understand test purpose

   This checks that clicking the button changes its class to 'active', common in complex UIs.

3. Final Answer:

   The button with class 'btn' is clicked and then has class 'active'. -> Option A

4. Quick Check:

   Click then check class = correct test [OK]

Hint: Click then assert class change means success [OK]

Common Mistakes:

• Ignoring the click() effect
• Thinking should() checks absence of class
• Confusing selection with clicking

4. Identify the error in this Cypress code snippet for a complex UI:

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

medium

A. 'should' cannot be chained after 'click'.

B. Incorrect selector syntax for 'get'.

C. Missing parentheses after 'click' command.

D. 'be.visible' is not a valid assertion.

Solution

1. Step 1: Check command syntax

   The click command requires parentheses: click().

2. Step 2: Verify chaining correctness

   With click() fixed, chaining should('be.visible') is valid to assert visibility.

3. Final Answer:

   Missing parentheses after 'click' command. -> Option C

4. Quick Check:

   click() needs parentheses [OK]

Hint: Always add () after commands like click [OK]

Common Mistakes:

• Omitting parentheses on commands
• Thinking selector syntax is wrong
• Believing should() can't follow click()

5. In a complex UI, a button initially has class 'disabled' and its class toggles between 'enabled' and 'disabled' after each click. Which Cypress code correctly tests this toggle behavior?

hard

A. cy.get('#toggleBtn').click().click().should('have.class', 'enabled')

B. cy.get('#toggleBtn').click().should('have.class', 'disabled').click().should('have.class', 'enabled')

C. cy.get('#toggleBtn').should('have.class', 'enabled').click().should('have.class', 'disabled')

D. cy.get('#toggleBtn').click().should('have.class', 'enabled').click().should('have.class', 'disabled')

Solution

1. Step 1: Understand toggle sequence

   The button starts with 'disabled', clicking toggles to 'enabled', then clicking again toggles back to 'disabled'.

2. Step 2: Match code to toggle logic

   cy.get('#toggleBtn').click().should('have.class', 'enabled').click().should('have.class', 'disabled') clicks once, checks 'enabled', clicks again, checks 'disabled', matching the toggle behavior.

3. Final Answer:

   cy.get('#toggleBtn').click().should('have.class', 'enabled').click().should('have.class', 'disabled') -> Option D

4. Quick Check:

   Click, check enabled, click, check disabled = correct toggle test [OK]

Hint: Test toggle by clicking and asserting classes in order [OK]

Common Mistakes:

• Reversing expected classes after clicks
• Missing initial class check
• Clicking twice before any assertion