Module 7 Summary
This lesson is a summary of module 7.0, where we started adding unit and integration tests to our app to increase our confidence our app works as expected.
Get the project source code below, and follow along with the lesson material.
Download Project Source CodeTo set up the project on your local machine, please follow the directions provided in the README.md
file. If you run into any issues with running the project source code, then feel free to reach out to the author in the course's Discord channel.
This lesson preview is part of the The newline Guide to Modernizing an Enterprise React App course and can be unlocked immediately with a \newline Pro subscription or a single-time purchase. Already have access to this course? Log in here.
Get unlimited access to The newline Guide to Modernizing an Enterprise React App, plus 70+ \newline books, guides and courses with the \newline Pro subscription.
[00:00 - 00:11] This lesson is a summary of what we have covered in Module 7. In this module, we learned why React Testing Library and Jest are the de facto testing frameworks for modern React applications.
[00:12 - 00:35] As the React framework has grown up and evolved, the testing frameworks used to ensure that the many pieces of an app continue to function have evolved alongside it. In the early days, Jest and Enzyme were the dynamic duo, but when hooks were released, a new contender emerged in the form of React Testing Library, and its unique perspective on testing caught on like wildfire.
[00:36 - 00:54] RTL took integration testing from a fairly brittle thing focused on the underlying implementation details to a more stable, more resilient model focused on the test interacting with the DOM, the same way that a user might. We learned how to set up hardware handler for integration testing success.
[00:55 - 01:09] Integration testing is an expected piece of any enterprise level React application, and many apps that are not yet that large. This testing gives us the confidence as developers that the code that we're writing isn't negatively impacting other parts of the app.
[01:10 - 01:36] With the addition of a few testing libraries in our package, JSONs, dev dependencies, and two new sets of commands in the scripts, we could not only run one or more integration tests at will, but also generate detailed code coverage reports that would display in the browser and show exactly which lines were and were not being tested. We also discussed testing strategies and recommendations about acceptable code coverage percentages.
[01:37 - 01:52] We learned how to integration test multiple different pieces of an application in this module. From functional components to custom hooks to API level JavaScript files, all of these things can be tested to make sure that they're working together correctly.
[01:53 - 02:02] In each lesson, we chose and tested a few files of each type to show many different examples of how it can be done. How to test happy paths when things went right.
[02:03 - 02:09] How to test unhappy paths when errors were thrown. How to set up MOCs and to share data among different test files.
[02:10 - 02:16] So our next module, the testing continues. We have end-to-end tests for hardware handler now.
[02:17 - 02:33] So while integration testing is one piece of the automated testing puzzle, another common practice is end-to-end testing. This is the practice of writing automated tests that go through a full user flow, interacting with the app in a fashion similar to how a user would.
[02:34 - 02:52] Because what's more important than an app working the way a user would expect it to. We'll employ popular end-to-end testing framework Cyprus in the next module and set it up and write automated tests that will recreate mission critical functionality in our app to make sure that users can do what they need to do.
[02:53 - 02:54] Let's get to it.