1. What makes cy.get('.count').should('have.text', '1') different from a plain expect?
Answer
The whole cy.get + should retries until the text is '1' or the command times out
Correct. Cypress retries the query and the assertion together. This absorbs loading time without any manual wait.
Retry-ability is why you rarely wait manually: cy.get(...).should(...) keeps re-checking until the condition holds or it times out.
Why the other answers are wrong
- It checks the text exactly once, immediately. That is how a plain expect works. .should retries until it passes or times out.
- It only works on elements with a class selector. Retry-ability is not tied to selector type. Any cy.get + should retries.
- It hides failures if the text is wrong. If the text never becomes '1', the assertion fails clearly. It does not hide anything.
2. When do you use expect() instead of .should() in Cypress?
Answer
Inside a .then() callback, to assert on a value you have already extracted
Correct. expect() is a plain assertion for values in hand. .should() is the retrying assertion on a command's subject.
.should() retries against a command's subject. expect() is a one-time check, used inside .then() on a value you already hold.
Why the other answers are wrong
- Always, expect() is the modern replacement for should(). They are not replacements. .should() retries; expect() runs once inside .then().
- Never, Cypress has no expect(). Cypress bundles Chai, so expect() is available, mainly inside .then().
- Only for numbers, not strings. expect() works on any value. The distinction is retrying (should) vs one-time (expect).
3. After adding one item, a test asserts cy.get('[data-testid="cart-count"]').should('be.visible'). Why is this a weak test?
Answer
The badge is visible whether it shows 0 or 1, so a broken counter still passes
Correct. 'Visible' does not check the value. The test passes even if the count never changed. Assert the exact text.
Assert the value the feature promises: .should('have.text', '1'). Presence checks pass on a broken app.
Why the other answers are wrong
- be.visible is not a real assertion. be.visible is real. It just checks visibility, not the value the user depends on.
- You cannot assert on a badge element. You can. The weakness is asserting presence instead of the number.
- It needs a cy.wait before the assertion. It does not need a wait. It needs to assert the value, not just visibility.
4. Which assertion proves the cart badge shows exactly 1 after adding one product?
Answer
cy.get('[data-testid="cart-count"]').should('have.text', '1')
Correct. This checks the exact value a broken counter would get wrong. It is the assertion the test needs.
have.text '1' is the assertion that fails on a broken counter. That is exactly what makes it a real test.
Why the other answers are wrong
- cy.get('[data-testid="cart-count"]').should('exist'). The badge exists whether it shows 0 or 1. This does not prove the count changed.
- cy.get('[data-testid="cart-count"]').should('be.visible'). Visibility does not check the number. A broken counter is still visible.
- cy.get('[data-testid="cart-count"]').its('length').should('eq', 1). That checks how many badge elements exist (one), not the number shown inside it.
5. After clicking 'Add to cart', which set of assertions is most complete?
Answer
Assert the badge reads '1' AND the confirmation toast appears
Correct. The user relies on both effects. Checking only one leaves the other free to break silently.
One action, several promises. Assert each effect the user depends on. The badge and the toast, not just the convenient one.
Why the other answers are wrong
- Assert only that the toast appears. A test that checks only the toast stays green if the badge counter breaks.
- Assert only that the badge reads '1'. That misses the confirmation the user also relies on. Assert both effects.
- Assert the page did not crash. Not crashing proves almost nothing about the cart behaviour.
6. What does .and() do, as in .should('be.visible').and('contain', 'Saved')?
Answer
It chains a second assertion on the same element
Correct. .and() is an alias of .should() that adds another assertion to the current subject.
.and() reads as a continuation of .should(): two assertions on the same element, both retried.
Why the other answers are wrong
- It selects a second element. .and() does not select. It adds an assertion to the current element.
- It runs the two assertions on different elements. Both assertions apply to the same subject the chain is on.
- It waits 2 seconds between the assertions. .and() adds no delay. It simply adds another assertion.
7. A search test asserts cy.contains('Maya Chen').should('be.visible') after filtering. Why can this pass even when the filter is broken?
Answer
If the filter is ignored, all rows stay, Maya is still among them, so she is still visible
Correct. Presence of one match does not prove the others were removed. Assert the row count instead.
Filtering is defined by what it removes. Assert cy.get(row).should('have.length', 1), not just that one match is visible.
Why the other answers are wrong
- cy.contains cannot be used after a filter. It can. The weakness is that Maya being visible does not prove filtering happened.
- be.visible always passes. be.visible can fail. Here it passes because Maya is on the page either way.
- The test needs a cy.wait after typing. A wait does not fix it. The assertion checks the wrong thing, presence, not the count.
8. Which assertion proves a search filtered the CRM table down to one row?
Answer
cy.get('[data-testid="contact-row"]').should('have.length', 1)
Correct. The row count going to 1 proves the non-matches were removed. This is what tests a filter.
have.length 1 is the assertion that fails when the filter is ignored. Count the result, do not just find one member.
Why the other answers are wrong
- cy.contains('Maya Chen').should('exist'). Maya can exist while all other rows also remain. This does not prove filtering.
- cy.get('[data-testid="search-input"]').should('have.value', 'Maya'). That only checks what you typed, not whether the table filtered.
- cy.get('[data-testid="contact-row"]').should('be.visible'). Rows being visible does not tell you how many remain.
9. A test fails because the app takes 700ms to update. What is the right fix?
Answer
Assert the final state with .should, Cypress retries until the value updates
Correct. The retrying assertion waits exactly as long as the update needs, with no fixed delay.
Let the assertion do the waiting. .should retries until the app finishes; no fixed wait is needed.
Why the other answers are wrong
- Add cy.wait(700) before the assertion. A fixed wait is a guess. On a slow run 700ms is not enough; on a fast run it wastes time.
- Add cy.wait(3000) to be safe. That makes every run 3 seconds slower and can still fail on a very slow run.
- Remove the assertion so the test cannot fail. A test that cannot fail proves nothing. Keep the assertion and let it retry.
10. What does .should('have.length', 8) assert?
Answer
That the current command yielded exactly 8 elements
Correct. have.length checks the number of matched elements, useful for row counts and lists.
have.length counts matched elements. cy.get(row).should('have.length', 8) is the baseline before a filter narrows it.
Why the other answers are wrong
- That an element's text is 8 characters long. That would be have.length on a string via its(); on an element set, have.length counts elements.
- That the element has 8 child nodes. have.length here counts the matched elements, not children.
- That you waited 8 seconds. have.length has nothing to do with time. It counts elements.