Child commands in Cypress - Deep Dive

Overview - Child commands

What is it?

Child commands in Cypress let you find elements inside other elements on a web page. They help you narrow down your search to children of a specific parent element. This makes tests more precise and easier to read. Instead of searching the whole page, you focus on a smaller part.

Why it matters

Without child commands, tests might select wrong elements or become slow because they search the entire page. This can cause flaky tests that fail randomly. Child commands make tests more reliable and faster by targeting exactly what you want. This saves time and frustration when testing web apps.

Where it fits

Before learning child commands, you should know basic Cypress commands like cy.get() to select elements. After child commands, you can learn about chaining commands, custom commands, and advanced selectors. Child commands are a key step in mastering element selection in Cypress.

Mental Model

Core Idea

Child commands let you find elements inside a specific parent element to make tests precise and reliable.

Think of it like...

It's like looking for a book inside a particular shelf instead of searching the whole library.

Parent element
┌───────────────┐
│               │
│  Child 1      │
│  Child 2      │
│  Child 3      │
└───────────────┘
Use child command to select only Child 2 inside this parent.

Build-Up - 7 Steps

1

Foundation

Basic element selection with cy.get()

Concept: Learn how to select elements on a page using cy.get() by CSS selectors.

Use cy.get('selector') to find elements. For example, cy.get('ul') finds all unordered lists on the page. This is the first step before narrowing down to children.

Result

The test finds all elements matching the selector on the page.

Understanding how to select elements globally is the base for using child commands effectively.

2

Foundation

Understanding parent and child elements

Concept: Know the HTML structure of parent and child elements to target children correctly.

HTML elements can contain other elements inside them. For example, a

(parent) contains
• items (children). Recognizing this helps you use child commands to find specific children.

Result

You can visualize the page structure and know where to look for elements.

Knowing the hierarchy of elements is essential to use child commands to find the right elements.

3

Intermediate

Using .children() to get direct children

🤔Before reading on: do you think .children() selects all descendants or only direct children? Commit to your answer.

Concept: The .children() command selects only the direct children of the current element, not deeper nested elements.

Example: cy.get('ul').children('li') This finds all

elements that are direct children of the

. It does not find grandchildren or deeper nested elements.

Result

The test selects only the immediate child elements matching the selector.

Understanding that .children() limits selection to direct children prevents selecting unintended nested elements.

4

Intermediate

Using .find() to get all descendants

🤔Before reading on: does .find() select only direct children or all nested descendants? Commit to your answer.

Concept: .find() selects all descendant elements inside the current element, at any depth.

Example: cy.get('div.container').find('button') This finds all

Result

The test selects all matching elements inside the parent, no matter how deeply nested.

Knowing .find() selects all descendants helps you choose between .children() and .find() based on how deep you want to search.

5

Intermediate

Chaining child commands for precise selection

🤔Before reading on: can you chain .children() and .find() together? What happens? Commit to your answer.

Concept: You can chain child commands to narrow down selection step-by-step inside nested elements.

Example: cy.get('div').children('ul').find('li.active') This first gets div, then its direct ul children, then finds all li with class active inside those ul. Chaining makes tests clear and precise.

Result

The test finds exactly the elements you want by narrowing scope progressively.

Chaining child commands lets you build complex selectors in a readable way, improving test clarity and reliability.

6

Advanced

Avoiding common pitfalls with child commands

🤔Before reading on: do you think .children() and .find() always return the same elements if used with the same selector? Commit to your answer.

Concept: Understand differences and limitations of child commands to avoid flaky or wrong tests.

Using .children() when you need deeper descendants will miss elements. Using .find() without limiting scope can select too many elements. Also, chaining commands without waiting for elements can cause timing issues. Use assertions and proper waits to avoid flaky tests.

Result

Tests become stable and select exactly the intended elements.

Knowing the subtle differences and timing issues with child commands prevents common test failures.

7

Expert

Custom child commands and performance tips

🤔Before reading on: do you think creating custom child commands can improve test readability and reuse? Commit to your answer.

Concept: You can create your own child commands in Cypress to encapsulate common child selection logic and improve test performance.

Example: Cypress.Commands.add('getActiveListItems', () => { return cy.get('ul').children('li.active') }) Using custom commands reduces duplication and makes tests easier to maintain. Also, limiting DOM queries with child commands improves test speed.

Result

Tests are cleaner, faster, and easier to update.

Creating custom child commands leverages Cypress's extensibility and improves large test suite maintainability.

Under the Hood

Cypress commands like .children() and .find() use jQuery selectors under the hood to query the DOM. When you call .children(), Cypress queries only the immediate child nodes of the current element. .find() performs a deeper search through all descendants. Cypress queues these commands and executes them asynchronously, syncing with the browser's DOM state to ensure elements exist before continuing.

Why designed this way?

Cypress uses jQuery selectors because they are powerful and well-tested for DOM traversal. Separating .children() and .find() gives testers control over search depth, improving precision and performance. The asynchronous command queue ensures tests wait for elements to appear, reducing flaky failures common in other tools.

cy.get('parent')
   │
   ├─ .children('selector') → selects immediate children
   │
   └─ .find('selector') → selects all descendants

Commands queue → executed asynchronously → DOM queried via jQuery selectors

Myth Busters - 4 Common Misconceptions

Quick: Does .children() select all nested elements inside a parent? Commit yes or no.

Common Belief: Many think .children() selects all nested elements inside a parent element.

Reality: .children() only selects direct children, not deeper nested descendants.

Why it matters: Using .children() expecting all descendants leads to missing elements and test failures.

Quick: Does .find() only select direct children? Commit yes or no.

Common Belief: Some believe .find() behaves like .children() and selects only direct children.

Reality: .find() selects all descendants at any depth inside the parent element.

Why it matters: Using .find() without care can select too many elements, causing flaky or slow tests.

Quick: Can chaining child commands cause timing issues if not handled properly? Commit yes or no.

Common Belief: Many assume chaining child commands always works instantly without timing problems.

Reality: Chaining commands can cause flaky tests if elements are not yet in the DOM or visible when commands run.

Why it matters: Ignoring timing can cause random test failures, wasting debugging time.

Quick: Does creating custom child commands only add complexity? Commit yes or no.

Common Belief: Some think custom child commands make tests more complex and harder to read.

Reality: Custom child commands improve readability, reuse, and maintainability in large test suites.

Why it matters: Avoiding custom commands leads to duplicated code and harder-to-maintain tests.

Expert Zone

1

Child commands interact with Cypress's automatic waiting, but improper chaining can still cause timing issues if elements appear dynamically.

2

Using .find() inside .children() can cause unexpected results if selectors overlap or if the DOM structure changes dynamically.

3

Custom child commands can encapsulate complex selectors and assertions, but overusing them can hide test logic and reduce clarity.

When NOT to use

Avoid child commands when testing elements outside a known parent or when you need to select elements globally. Instead, use cy.get() with unique selectors or data attributes. For very dynamic content, consider using Cypress's .within() command to scope commands inside a block.

Production Patterns

In real-world tests, child commands are used to scope selectors to components or sections, reducing flakiness. Teams create custom child commands for repeated patterns like selecting active menu items or form fields inside modals. Combining child commands with aliases and .within() improves test readability and performance.

Connections

CSS Selectors

Child commands build on CSS selector concepts to target elements precisely.

Understanding CSS selectors deeply helps write better child commands and avoid selecting wrong elements.

Asynchronous Programming

Cypress child commands run asynchronously and queue commands to sync with the browser.

Knowing asynchronous behavior helps prevent timing issues and flaky tests when chaining child commands.

Hierarchical Data Structures

Child commands reflect the tree structure of HTML elements, similar to nodes in data trees.

Recognizing DOM as a tree helps understand why .children() and .find() differ in depth of search.

Common Pitfalls

#1 Selecting too broadly with .find() causes tests to pick wrong elements.

Wrong approach:

cy.get('form').find('input') // selects all inputs inside form, including nested unrelated ones

Correct approach:

cy.get('form').children('input') // selects only direct input children of form

Root cause:

Misunderstanding that .find() searches all descendants, not just direct children.

#2 Using .children() when elements are nested deeper misses targets.

Wrong approach:

cy.get('div.container').children('button') // no buttons are direct children, so none found

Correct approach:

cy.get('div.container').find('button') // finds buttons nested anywhere inside container

Root cause:

Confusing direct children with all descendants in the DOM hierarchy.

#3 Chaining child commands without waiting causes flaky tests.

Wrong approach:

cy.get('ul').children('li').click() // li may not be ready yet

Correct approach:

cy.get('ul').children('li').should('be.visible').click() // waits for li to be visible

Root cause:

Ignoring Cypress's automatic waiting and element readiness before actions.

Key Takeaways

Child commands in Cypress let you select elements inside a specific parent to make tests precise and reliable.

.children() selects only direct children, while .find() selects all descendants at any depth.

Chaining child commands helps narrow down element selection step-by-step for clarity and accuracy.

Understanding the DOM hierarchy and asynchronous command execution prevents common test failures.

Creating custom child commands improves test reuse, readability, and maintainability in large projects.

Practice

1. What does the .find() command do in Cypress testing?

easy

A. It clicks on an element.

B. It types text into an input field.

C. It waits for a page to load.

D. It locates child elements inside a parent element.

Solution

1. Step 1: Understand the purpose of .find()

   The .find() command is used to search for elements inside another element, meaning it looks for child elements.

2. Step 2: Compare with other commands

   Commands like .click(), .type(), and .wait() perform actions or wait, but do not locate child elements.

3. Final Answer:

   It locates child elements inside a parent element. -> Option D

4. Quick Check:

   .find() locates children = B [OK]

Hint: Remember: .find() searches inside a parent element [OK]

Common Mistakes:

• Confusing .find() with .click() or .type()
• Thinking .find() waits for elements
• Using .find() without a parent element

2. Which of the following is the correct syntax to find a button inside a div with class container using Cypress?

easy

A. cy.get('.container').find('button')

B. cy.find('.container').get('button')

C. cy.get('button').find('.container')

D. cy.find('button').get('.container')

Solution

1. Step 1: Understand chaining commands in Cypress

   First, cy.get() selects the parent element. Then, .find() locates child elements inside it.

2. Step 2: Analyze each option

   cy.get('.container').find('button') correctly uses cy.get('.container') to select the parent, then .find('button') to find the child button. Other options misuse the order or commands.

3. Final Answer:

   cy.get('.container').find('button') -> Option A

4. Quick Check:

   Parent first with get(), then child with find() = A [OK]

Hint: Use cy.get() first, then .find() for child elements [OK]

Common Mistakes:

• Swapping .get() and .find() order
• Using .find() without cy.get() first
• Selecting child before parent

3. What will the following Cypress code select?

cy.get('ul.menu').find('li.active').should('have.length', 2)

medium

A. It selects all li elements inside ul.menu with class active and checks there are 2.

B. It selects 2 ul elements with class menu.

C. It clicks on the first li.active element.

D. It types '2' into the ul.menu element.

Solution

1. Step 1: Understand the selector chain

   cy.get('ul.menu') selects the ul element with class menu. Then .find('li.active') finds li children with class active.

2. Step 2: Understand the assertion

   .should('have.length', 2) asserts that exactly 2 such li.active elements exist inside the ul.menu.

3. Final Answer:

   It selects all li elements inside ul.menu with class active and checks there are 2. -> Option A

4. Quick Check:

   Find children with class and check count = A [OK]

Hint: Find children, then assert count with .should('have.length') [OK]

Common Mistakes:

• Confusing parent and child selectors
• Thinking it clicks or types instead of asserting
• Misreading the assertion purpose

4. Identify the error in this Cypress code snippet:

cy.find('.list').get('li').should('have.length', 3)

medium

A. There is no error; the code is correct.

B. The selector '.list' is invalid.

C. The order of commands is incorrect; .get() should come before .find().

D. The assertion .should('have.length', 3) is not valid.

Solution

1. Step 1: Check command order

   cy.find() is not a valid starting command. cy.get() must be used first to select the parent element.

2. Step 2: Correct usage

   The correct order is cy.get('.list').find('li') to find li children inside the element with class list.

3. Final Answer:

   The order of commands is incorrect; .get() should come before .find(). -> Option C

4. Quick Check:

   Use cy.get() first, then .find() = D [OK]

Hint: Always start with cy.get() before .find() [OK]

Common Mistakes:

• Starting with .find() instead of cy.get()
• Assuming .find() works alone
• Ignoring command chaining rules

5. You want to verify that a form with id login contains exactly 3 input fields that are visible. Which Cypress code correctly uses child commands to do this?

hard

A. cy.find('#login').get('input:visible').should('have.length', 3)

B. cy.get('#login').find('input:visible').should('have.length', 3)

C. cy.get('#login').find('input').should('have.length', 3).and('be.visible')

D. cy.get('input:visible').find('#login').should('have.length', 3)

Solution

1. Step 1: Select the parent form element

   Use cy.get('#login') to select the form with id 'login'.

2. Step 2: Find visible input children and assert count

   Use .find('input:visible') to get visible input fields inside the form, then assert there are exactly 3 with .should('have.length', 3).

3. Final Answer:

   cy.get('#login').find('input:visible').should('have.length', 3) -> Option B

4. Quick Check:

   Parent get(), then find visible inputs, then check length = C [OK]

Hint: Chain get() then find(':visible') before asserting length [OK]

Common Mistakes:

• Using .find() before cy.get()
• Checking visibility after length assertion
• Incorrect selector order