#100DaysOfCode: Day 5
Day 5 of #100DaysOfCoding! This week we had a lesson on Cypress. Before I explain what Cypress is, let’s take a step back to understand what is testing and test-driven development
Testing
Why do we test code before building it? Writing tests for code forces the developer to think about the application at a high level before digging into the program function by function. Doing this can help us avoid pitfalls when designing classes and how they interact with each other.
Does this function return the data type we expect? Does this piece of data need to be its own class or can it be a parameter passed through another class? Is the user seeing what we expect? These types of questions can be answered by creating a thorough test suite from the beginning.
Types of Testing
Let’s talk about the different types of tests. From the more narrow to the broadest type of test.
1. Unit testing (most narrow type of test)
- Unit testing will test one function at a time. It usually tests the expected output of a function.
- This is a developer test. This only concerns the developer, not the user.
2. Integration Testing
- Integration tests work to understand how two functions work together. Does function A call function B? What output do we expect when they work together?
- Another developer test. Only concerns the developer, not the user.
3. Acceptance Testing
- Ensures the acceptance criteria for a user story have been met.
- For example, think of a login page. Acceptance criteria for a login page could be — when a user clicks submit, the user views the home page.
- This type of test looks to understand the flow of the app from the user’s perspective.
- A test from the User’s POV. Concerns with what the user sees.
4. End to End “E2E” Testing (the broadest type of test)
- Gets the application ready to ship to production.
- Tests the entire application (the client, databases, API, etc).
Cypress and why do we care?
Well, you may not care if you are not a dev. Cypress is a testing library for React. React comes with built-in keywords we can use to test the user experience. Cypress helps us devs with the last two types of tests (Acceptance & E2E).
Testing the user experience as a dev can be tedious. If we need to test a very specific part of your application, just getting to that portion of the application upon reload can take very many clicks. This problem multiples when we need to test multiple inputs for a specific piece of functionality. If we have to test these parts of our application manually, we lose valuable time that could otherwise be spent coding.
This is where Cypress’ magic comes into play. We can write tests similar to how we would with Mocha and Chai during unit testing. However, they can be checked 100% automatically without the developer having to make several clicks to test a specific feature.
Huzzah! This will save me incredible amounts of time in the future and I can spend that time towards more productive endeavors.
Above is a picture of our implementation of Cypress into our current project. The UI of Cypress is very neat and intuitive — thanks devs! I will dive deeper into creating tests with Cypress at a later date as I keep working with this new technology.
