Putting it together: a suite people trust

You now know the pieces. This lecture is about assembling them into something a team runs every day, because a suite is more than a pile of tests.

Decide what goes in it.

Not everything. A regression suite protects the journeys that cost money when they break. For a typical product that is: sign in, the main create-and-view flow, checkout or whatever completes the transaction, and the permissions that keep users out of each other's data.

Anything you can check more cheaply elsewhere should be checked elsewhere. Field validation logic, currency formatting, date maths: those are unit tests, and putting them in the browser suite makes it slow without making it safer.

Organise it by feature, not by page.

cypress/
  e2e/
    smoke/
      login.cy.js
      dashboard-loads.cy.js
    contacts/
      create.cy.js
      search-and-filter.cy.js
      delete.cy.js
    checkout/
      payment.cy.js
  fixtures/
  support/
    commands.js

The smoke folder is the small set that runs first, on every commit. If it fails, nothing else needs to run. The rest runs after, or nightly if it is long.

Make every test independent.

This is the rule the whole track has been building toward, so it is worth stating once more in its final form. Each spec:

• creates its own data, with unique values
• logs in through cy.session rather than depending on a previous test
• arranges through the API where the UI is not the point
• asserts on its own records, never on totals it does not control

A suite built this way can run in any order and in parallel. A suite that is not built this way cannot be made parallel later without rewriting it, which is why this is a decision you make at the start.

Plan for it getting slow.

Every suite slows down as it grows. The order to reach for fixes:

1. Arrange through the API. Usually the single biggest win, because form-filling dominates most suites.
2. Reuse the session. cy.session turns forty logins into one.
3. Split the run. Most CI systems can run specs across several machines at once. This works only if your tests are independent.
4. Delete tests. The unpopular one. A test that has never failed in two years and covers a screen nobody uses is costing you time on every run. Removing it is a legitimate decision, not an admission of failure.

Have an answer for flaky tests before you have any.

Agree the rule with your team on a calm day: a test that fails intermittently gets fixed within a set time, or it gets deleted. What kills suites is the middle option, where a flaky test stays red-ish for months and everyone learns to shrug at red.

Remember this: a suite is a product with users, and its users are your team. If they do not trust the red, none of the rest matters.

Reference: Cypress best practices.