Cypress as a Development Tool

Up to this point, we have tested an existing front-end application. Usually, however, we actually write the tests after the entire implementation (frontend and backend).

While we code the flow, we want to avoid fighting with erring testing. This is why we manually test the half-built flow. However, we often spend a considerable amount of time using components with temporary props and hard-coding temporary snippets which send us directly to the desired state of the app. When we finish, we remove all the temporary code and start writing the tests.

Limintations

This process has a lot of limitations:

• Manually interacting with the app is very slow.

• Adding temporary code to the codebase is potentially dangerous.

• The tests we will write just perform the same actions that we do manually(like interacting with the app).

Consider our recent experience with Cypress:

• Cypress is quick when interacting with the page.

• The UI tests do not require special temporary code.

• Cypress allows us to act as the back-end, simulating real network conditions from a browser perspective.

What is blocking us from using Cypress during the development phase and not only during the test phase? After all, Cypress

• ✅ is always open

• ✅ relaunches the tests as soon as the test file is saved.

• ✅ relaunches the test every time the application refreshes because of the Webpack DevServer.

• ✅ allows you to use the Chrome DevTools (the Electron ones)

even when

• ⚠️ the real Chrome DevTools are more powerful than the Electron ones

• ❌ we can not install the React/Redux DevTools into Electron

• ⚠️ going back and forth between the test code tand running the test can be tedious.

The solution

Did you know that Cypress can be launched in every Chrome version? Did you know that Cypress creates a dedicated (and persistent) Chrome user?

Take a look at the upper right corner of the Cypress list of tests: