Testing components on high-level patterns

Testing is something very important when it comes to creating reliable and stable applications. First of all, let's look at the most common three types of tests you will need to write:

• Trivial unit tests: I don't understand it, but is it working or not working at all? Usually, tests that check whether the component renders or whether the function runs with no errors are called trivial unit tests. If you do this manually, you call these tests smoke tests. Such tests are vital to have. Whether you like it or not, you should write trivial tests, at least to know if every feature is somehow working.
• Unit tests: Does the code work as I expect it to? Does it work in all of the code branches? By branch, we mean places in the code where it branches, for instance, if statements are branching code into different code paths, which is similar to switch-case statements. Unit testing refers to testing a single unit of code. In crucial features of an application, unit tests should cover whole function code (as a principle: 100% code coverage for crucial features).
• Snapshot tests: Testing if the previous and actual version produce the same result is called snapshot testing. Snapshot tests are just creating text output, but once the output is proven to be correct (through developer assessment and code review), it may work as a comparison tool. Try to use snapshot tests a lot. Such tests should be committed into your repository and undergo review process. This new feature in Jest saves a lot of time for developers:
  • Image snapshot tests: In Jest, snapshot tests compare text (JSON to JSON), however, you may encounter references to snapshot tests on mobile devices, where this means comparing images to images. This is a more advanced topic, but is commonly used by big websites. Taking such a screenshot most likely requires building the whole app instead of a single component. Building the whole app is time-consuming, so some companies only run these type of tests when they plan for a release, for instance, on a release candidate build. This strategy can be automated to follow continuous integration and continuous delivery principles.

Since we are using the CRNA toolbox in this book, the testing solution you want to check is Jest (https://facebook.github.io/jest/).

There are usually some metrics to testing, such as code coverage (the number of lines covered by tests), the number of reported bugs, and the number of registered errors.

Although very valuable, these may create a false belief that the application is well-tested.

There are a few utterly wrong practices that I need to mention when it comes to testing patterns:

• Relying only on unit tests: Unit tests mean testing just a single piece of code in isolation, for instance, a function by passing arguments to it and checking the output. This is great and saves you from a lot of bugs, but no matter what code coverage you have, you may bump into problems with the integration of well-tested components. The real-life example I like to use is a video of two sliding doors that are placed too close to each other, which causes them to keep on opening and closing forever. 
• Relying on code coverage too much: Stop stressing yourself or other developers to reach that 100% or 90% code coverage mark. If you can afford it, great, but usually it makes developers write less valuable tests. Sometimes, it is crucial to send different integer values to functions; for instance, when testing division, it is not enough to send two positive integers. You need to also check what happens when you divide by zero. Coverage won't tell you that.
• Not tracking how your testing metrics influence the number of bugs: If you just rely on some metrics, whether it be code coverage or any other, please reassess if the metrics tell the truth, for instance, whether increase in the metric causes less bugs. To give you a nice example, I've heard developers from many different companies say that the code coverage increasing above 80% didn't help them much.