Cypress as a Development Tool
Explore how Cypress can be used during front-end development to avoid manual testing delays, simulate backend conditions, and integrate with Chrome DevTools. Learn practical tips for faster testing workflows and improving productivity without adopting TDD.
We'll cover the following...
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:
Cypress allows us to choose between the Chrome instances it might find on our machine. For instance, some people might prefer to use Chrome Canary for testing rather than the standard Chrome to have a different (yellow) icon and recognize immediately the testing-dedicated browser.
With Cypress, we can install the React and Redux Devtools in a Real Chrome browser that we choose. Note: these extensions can be found on the Chrome extension website.
We can use Chrome in conjunction with Cypress in all of our projects! So, once we have installed our extensions of choice, we can use them for every project.
To work the React DevTools you must simply add the following snippet to the public/index.html of your create-react-app project.
<script>
if (window.Cypress) {
window["__REACT_DEVTOOLS_GLOBAL_HOOK__"] =
window.parent["__REACT_DEVTOOLS_GLOBAL_HOOK__"];
}
</script>
to the public/index.html of your create-react-app project. This snippet is needed because the React app runs inside an iframe when launched under Cypress
About the Chrome DevTools console: to access the global scope of your app you need to change the JavaScript context in the upper-left corner of the console itself. See the next screenshot where window.appActions (defined during the App Actions lesson ) becomes available only after a context selection.
To avoid going back and forth between the code test and to select or exclude the test, we can add the cypress-skip-and-only-ui plugin. This plugin adds some buttons to the Test Runner that allow us to run a specific test, skip a test, or restore the standard test order. This takes away the necessity to manually add .only or .skip to your tests.
All the above tips should guide you towards a new way of developing apps and tests. At the very least, it teaches you that cy.findByPlaceholderText("Username").type("Foo") is much faster than manual typing.
Please note that this is not TDD(Test-driven development)!We have disucssed how to leverage a testing tool to improve our productivity, but our aim is not to start TDDing. TDD should not be a factor until you are a practiced testing developer alongside a team that supports you.