- Anti-Pattern: Sharing page objects, using your UI to log in, and not taking shortcuts.
- Best Practice: Test specs in isolation, programmatically log into your application, and take control of your application's state.
- Anti-Pattern: Using highly brittle selectors that are subject to change.
Best Practice: Use
data-*attributes to provide context to your selectors and isolate them from CSS or JS changes
||Never||Worst - too generic, no context|
||Never||Bad. Coupled to styling. Highly subject to change|
||Sparingly||Better. But still coupled to styling or JS event listeners.|
||Sparingly||Coupled to the name attribute which has HTML semantics.|
||Depends||Much better. But still coupled to text content that may change.|
||Always||Best. Isolated from all changes.|
Anti-Pattern: Trying to assign the return value of Commands with
- Best Practice: Use closures to access and store
- Anti-Pattern: trying to visit or interact with sites or servers you do not control
Best Practice: Only test what you control. Try to avoid requiring a 3rd party server. When necessary, always use
cy.request()to talk to 3rd party servers via their APIs.
- Anti-Pattern: Coupling multiple tests together
- Best Practice: Tests should always be able to be run independently from one another and still pass.
- Anti-Pattern: Acting like you're writing unit tests.
- Best Practice: Add multiple assertions and don't worry about it
afterEachhooks to clean up state.
- Best Practice: Clean up state before tests run.
Anti-Pattern: Waiting for arbitrary time periods using
- Best Practice: Use route aliases or assertions to guard Cypress from proceeding until an explicit condition is met
Anti-Pattern: Trying to start a web server from within Cypress scripts with
- Best Practice: Start a web server prior to running Cypress
cy.visit()without setting a
Best Practice: Set a
baseUrlin your configuration file (cypress.json by default)
You can read our entire Best Practices Guide at https://docs.cypress.io/guides/references/best-practices