Cypress is a nice tool for end-to-end tests and it has good documentation also for Best Practices including “Cypress Best Practices” talk by Brian Mann at Assert(JS) 2018. Here are my notes from the talk combined with the Cypress documentation. This article assumes you know and have Cypress running.
In short:
- Set state programmatically, don’t use the UI to build up state.
- Write specs in isolation, avoid coupling.
- Don’t limit yourself trying to act like a user.
- Tests should always be able to be run independently and still pass.
- Only test what you control.
- Use data-* attributes to provide context to your selectors.
- Clean up state before tests run (not after).
I’ve also made slides for this and they can be found on SlideShare.
Update 20.1.2022: Cypress own documentation for Best Practices contains more detailed explanations and for practical approach the Cypress team maintains the Real World App (RWA), a full stack example application that demonstrates best practices and scalable strategies with Cypress in practical and realistic scenarios.
Organizing tests
- Don't use page objects to share UI knowledge
+ Write specs in isolation, avoid coupling“Writing and Organizing tests” documentation just tells you the basics how you should organize your tests. You should organize tests by pages and by components as you should test components individually if possible. So the folder structure for tests might look like.
├ articles ├── article_details_spec.js ├── article_new_spec.js ├── article_list_spec.js ├ author ├── author_details_spec.js ├ shared ├── header_spec.js ├ user ├── login_spec.js ├── register_spec.js └── settings_spec.js
Selecting Elements
- Dont' use highly brittle selectors that are subject to change.
+ Use data-* attributes to provide context to your selectors and insulate them from CSS or JS changes.Add data-* attributes to make it easier to target elements.
For example:
<button id="main" class="btn btn-large" name="submit"
role="button" data-cy="submit">Submit</button>Writing Tests
- Don't couple multiple tests together.
+ Tests should always be able to be run independently and still pass.Best practice when writing tests on Cypress is to iterate on a single one at a time, i.a.
describe('/login', () => {
beforeEach() => {
// Wipe out state from the previous tests
cy.visit('/#/login')
}
it('requires email', () =>
cy.get('form').contains('Sign in').click()
cy.get('.error-messages')
.should('contain', 'email can\'t be blank')
})
it('requires password', () => {
cy.get('[data-test=email]').type('joe@example.com{enter}')
cy.get('.error-messages')
.should('contain', 'password can\'t be blank')
})
it('navigates to #/ on successful login', () => {
cy.get('[data-test=email]').type('joe@example.com')
cy.get('[data-test=password]').type('joe{enter}')
cy.hash().should('eq', '#/')
})
})
Note that we don’t add assertions about the home page because we’re on the login spec, that’s not our responsibility. We’ll leave that for the home page which is the article spec.
Controlling State
“abstraction, reusability and decoupling”
- Don't use the UI to build up state
+ Set state directly / programmaticallyNow you have the login spec done and it’s the cornerstone for every single test you will do. So how do you use it in e.g. settings spec? For not to copy & paste login steps to each of your tests and duplicating code you could use custom command: cy.login(). But using custom command for login fails at testing in isolation, adds 0% more confidence and accounts for 75% of the test duration. You need to log in without using the UI. And to do that depends of how your app works. For example you can check for JWT token in the App and in Cypress make a silent (HTTP) request.
So your custom login command becomes:
Cypress.Commands.add('login', () => {
cy.request({
method: 'POST',
url: 'http://localhost:3000/api/users/login',
body: {
user: {
email: 'joe@example.com',
password: 'joe',
}
}
})
.then((resp) => {
window.localStorage.setItem('jwt', resp.body.user.token)
})
})
Setting state programmatically isn’t always as easy as making requests to endpoint. You might need to manually dispatch e.g. Vue actions to set desired values for the application state in the store. Cypress documentation has good example of how you can test Vue web applications with Vuex data store & REST backend.
Visiting external sites
- Don't try to visit or interact with sites or servers you do not control.
+ 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 like testing log in when your app uses another provider via OAuth. Or you could try stub out the OAuth provider. Cypress has recipes for different approaches.
Add multiple assertions
- Don't create "tiny" tests with a single assertion and acting like you’re writing unit tests.
+ Add multiple assertions and don’t worry about itCypress runs a series of async lifecycle events that reset state between tests. Resetting tests is much slower than adding more assertions.
it('validates and formats first name', function () {
cy.get('#first')
.type('johnny')
.should('have.attr', 'data-validation', 'required')
.and('have.class', 'active')
.and('have.value', 'Johnny')
})
Clean up state before tests run
- Don't use after or afterEach hooks to clean up state.
+ Clean up state before tests run.When your tests end – you are left with your working application at the exact point where your test finished. If you remove your application’s state after each test, then you lose the ability to use your application in this mode or debug your application or write a partial tests.
Unnecessary Waiting
- Don't wait for arbitrary time periods using cy.wait(Number).
+ Use route aliases or assertions to guard Cypress from proceeding until an explicit condition is met.For example waiting explicitly for an aliased route:
cy.server()
cy.route('GET', /users/, [{ 'name': 'Maggy' }, { 'name': 'Joan' }]).as('getUsers')
cy.get('#fetch').click()
cy.wait('@getUsers') // <--- wait explicitly for this route to finish
cy.get('table tr').should('have.length', 2)
No constraints
You’ve native access to everything so don’t limit yourself trying to act like a user. You can e.g.
- Control Time: cy.clock(), e.g. control how your app responds to system time, force set timeouts and set intervals to fire when you want them to.
- Stub Objects: cy.stub(), force callbacks to fire, assert things are called with right arguments.
- Modify Stores: cy.window(), e.g. dispatch events, like logout.
Set global baseUrl
+ Set a baseUrl in your configuration file.Adding a baseUrl in your configuration allows you to omit passing the baseUrl to commands like cy.visit() and cy.request().
Without baseUrl set, Cypress loads main window in localhost + random port. As soon as it encounters a cy.visit(), it then switches to the url of the main window to the url specified in your visit. This can result in a ‘flash’ or ‘reload’ when your tests first start. By setting the baseUrl, you can avoid this reload altogether.
Assertions should be obvious
“A good practice is to force an assertion to fail and see if the error message and the output is enough to know why. It is easiest to put a .only on the it block you’re evaluating. This way the application will stop where a screenshot is normally taken and you’re left to debug as if you were debugging a real failure. Thinking about the failure case will help the person who has to work on a failing test.” (Best practices for maintainable tests)
<code>
it.only('check for tab descendants', () => {
cy
.get('body')
.should('have.descendants', '[data-testid=Tab]') // expected '' to have descendants '[data-testid=Tab]'
.find('[data-testid=Tab]')
.should('have.length', 2) // expected '[ <div[data-testid=tab]>, 4 more... ]' to have a length of 2 but got 5
});
</code>Explore the environment
You can pause the test execution by using debugger keyword. Make sure the DevTools are open.
it('bar', function () {
debugger
// explore "this" context
})Running in CI
If you’re running in Cypress in CI and need to start and stop your web server there’s recipes showing you that.
Try the start-server-and-test module. It’s good to note that when using e2e-cypress plugin for vue-cli it starts the app automatically for Cypress.
If your videos taken during cypress run freeze when running on CI then increase the CPU resources, see: #4722
Adjust the compression level on cypress.json to minimal with "videoCompression": 0 or disable it with "videoCompression": false. Disable recording with "video": false.
Record success and failure videos
Cypress captures videos from test runs and whenever a test fails you can watch the failure video side by side with the video from the last successful test run. The differences in the subject under test are quickly obvious as Bahtumov’s tips suggests.
If you’re using e.g. GitLab CI you can configure it to keep artifacts from failed test runs for 1 week, while keeping videos from successful test runs only for a 3 days.
artifacts:
when: on_failure
expire_in: '1 week'
untracked: true
paths:
- cypress/videos
- cypress/screenshots
artifacts:
when: on_success
expire_in: '3 days'
untracked: true
paths:
- cypress/screenshots
Helpful practices
Disable ServiceWorker
ServiceWorkers are great but they can really affect your end-to-end tests by introducing caching and coupling tests. If you want to disable the service worker caching you need to remove or delete navigator.serviceWorker when visiting the page with cy.visit.
it('disable serviceWorker', function () {
cy.visit('index.html', {
onBeforeLoad (win) {
delete win.navigator.__proto__.serviceWorker
}
})
})Note: once deleted, the SW stays deleted in the window, even if the application navigates to another URL.
Get command log on failure
In the headless CI mode, you can get a JSON file for each failed test with the log of all commands. All you need is cypress-failed-log project and include it from your cypress/support/index.js file.
Conditional logic
Sometimes you might need to interact with a page element that does not always exist. For example there might a modal dialog the first time you use the website. You want to close the modal dialog. But the modal is not shown the second time around and the above code will fail.
In order to check if an element exists without asserting it, use the proxied jQuery function Cypress.$:
const $el = Cypress.$('.greeting')
if ($el.length) {
cy.log('Closing greeting')
cy.get('.greeting')
.contains('Close')
.click()
}
cy.get('.greeting')
.should('not.be.visible')Summary
- Don't use the UI to build up state + Set state directly / programmatically - Don't use page objects to share UI knowledge + Write specs in isolation, avoid coupling - Don't limit yourself trying to act like a user + You have native access to everything - Don't couple multiple tests together. + Tests should always be able to be run independently and still pass. - Don't try to visit or interact with sites or servers you do not control. + Only test what you control. - Dont' use highly brittle selectors that are subject to change. + Use data-* attributes to provide context to your selectors - Don't create tests with a single assertion + Add multiple assertions and don’t worry about it - Don't use after or afterEach hooks to clean up state. + Clean up state before tests run. + Set a baseUrl in your configuration file.
More to read
Use cypress-testing-library which encourage good testing practices through simple and complete custom Cypress commands and utilities.
Set up intelligent code completion for Cypress commands and assertions by adding a triple-slash directive to the head of your JavaScript or TypeScript testing spec file. This will turn the IntelliSense on a per file basis.
/// <reference types="Cypress" />Read What I’ve Learned Using Cypress.io for the Past Three Weeks if you need a temporary workaround for iframes and testing file uploads as for now Cypress does not natively support those.
And of course Gleb Bahmutov’s blog is useful resource for practical things like Tips and tricks post.
Leave a Reply