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.

This time, we will demonstrate a tricky part of snapshot testing.

Let's start by creating our first snapshot test. Go to Chapter_1/Example 4_Stateful_expandable_component and run yarn test in the command line. You should see that one test passes. What kind of test is it? It's a trivial unit test that's located in the App.test.js file.

It's time to create our first snapshot test. Replace expect(rendered).toBeTruthy(); with expect(rendered).toMatchSnapshot();. It should look like this:

it('renders', () => {
  const rendered = renderer.create(<App />).toJSON();
  expect(rendered).toMatchSnapshot();
});

Once you have this, rerun yarn test. A new directory called __snapshots__ should be created with the App.test.js.snap file inside it. Take a look at its contents. This is your first snapshot.

It's time to test the app's coverage. You can do this with the following command:

yarn test -- --coverage

It yields something a little concerning:

File     |  % Stmts | % Branch |  % Funcs |  % Lines | Uncovered Line #s
All files|    66.67 |       50 |       50 |    66.67
App.js   |    66.67 |       50 |       50 |    66.67 | 18,23,26

We have one component that has one branch (if), and after performing a snapshot test, the coverage is not even near 100%. What's wrong?

There is obviously a problem with the branch that relies on state, but would it account for over 30% of the lines? Let's see the full report. Open the ./coverage/lcov-report/App.js.html file:

Now, you see what is wrong. The answer is pretty simple—snapshot tests do not test prop functions. Why? First of all, this does not make much sense. Why would we convert a function to JSON, and how would it help? Secondly, tell me how to serialize the function. Shall I return function code as text or compute output in some other way?

Take this example as a lesson that snapshot tests are not enough.

You will often hear about the test-driven development (TDD) approach, which basically means writing tests first. To simplify this, let's summarize this in the following three steps:

1. Write tests and watch them fail.
2. Implement functionality until you see your tests passing.
3. Refactor to the best practices (optional).

I must admit that I really love this approach. However, the truth is that most developers will glorify this approach and barely any will use it. This is usually because it's time-consuming and it is hard to predict what the thing you are about to test looks like.

Going further, you will find that one of the test types is against TDD. Snapshot tests can only be created if the component is implemented, as they rely on its structure. This is another reason why snapshot tests are more of an addition to your tests rather than a replacement.

This approach works best in huge applications that go on for years, where a team of tech architects plan the interfaces and patterns to be used. This is most likely in backend projects, and you will have a general idea of how all of the classes and patterns connect to each other. Then, you simply take the interface and write the tests. Next, you follow up with implementation. If you want to create interfaces in React Native, you will need to support TypeScript.

Some argue that TDD is great in small projects, and you may quickly find such threads on Stack Overflow. Don't get me wrong; I'm happy that some people are happy. However, small projects tend to be very unstable and are likely to change often. If you are building a Minimum Viable Product (MVP), it doesn't work very well with TDD. You are better off relying on the fact that the libraries you use are well-tested and deliver the project on time, while quickly testing it with snapshots.

To summarize: abandoning TDD should not mean writing less tests.