First, why do we need tests?
Let’s suppose you are a developer. Now let’s suppose you are a front-end developer. Imagine that you have been recently hired to perform this role in a company that has a large, complex React web application. You see that managing such a complex application is a struggle. You don’t understand the actual flow of information, you see that there’s some inexplicable logic that you are afraid to touch, there’s a deep component nesting architecture, and so on.
If someone told you to make some changes in this codebase, this would probably be your reaction: 😱.
But you recall hearing from some wise white-haired man that there’s a way to manage such complexity. That man used a specific word to address this problem: refactoring! This is typically done when you want to rewrite a piece of code in a simpler way, breaking the logic into smaller chunks to reduce complexity.
Before you proceed, you remember that this is a very complex application. How can you be sure that you’re not breaking anything? You recall something else from the wise old man: testing!
Our choice for front end
At Cloud Academy, we have our large complex application built on a stack composed of React/Styled Components/Redux/Redux saga. The sagas are responsible for making the Rest API calls and updating the global state, while components will receive that state, updating the UI accordingly.
So, given our React stack, our choice was:
jest as test runner, mocking and assertion library
@testing-library/react or enzyme for unit testing React components (depending on the test purpose, or the project)
cypress for end-to-end testing (which will not be covered in this article)
Testing Library vs. Enzyme
Even though these two libraries both result in testing React components, they differ significantly in how the test is performed.
Enzyme focuses testing on implementation details, since you need to know the