What is the trade-off of cy.wait('@alias') vs implicit wait via .should?

Cypress's auto-waiting via .should and the explicit cy.wait('@alias') solve overlapping problems differently.

cy.wait('@alias') — explicit. You aliased a request with cy.intercept(...).as('cart'), and now you wait for that request to complete. The yielded interception object lets you assert on request (URL, body, headers) or response (status, body). Use this when:

• You need to assert on the request itself.
• You need to know data has actually loaded before asserting on derived UI.
• The page makes multiple requests and you care about a specific one.

.should(...) — implicit. Cypress retries the chain until the assertion passes or times out. Use this when:

• You only care about the visible state, not which request produced it.
• The same UI could be served from cache, from a different endpoint, etc.
• You're chaining multiple assertions on a query.

The trade-off:

• cy.wait('@alias') is more deterministic but more brittle — if the request shape changes (URL, query string, batched endpoint), the alias stops matching.
• .should is more resilient but less informative — a UI that asserts as expected might still be wrong if it's served from stale cache.

A practical pattern: use cy.wait('@alias') for the critical request gate, then .should for the assertions on the rendered UI:

cy.intercept('GET', '/api/cart').as('cartLoad');
cy.visit('/cart');
cy.wait('@cartLoad');                                    // gate: data is here
cy.get('[data-test=total]').should('contain', '£42.50'); // assert: UI is correct