Testing · React Native

Your tests should be short and ideally test only one thing.

The test in the image is described by the string passed to the it function. Take good care writing the description so that it’s clear what is being tested. Do your best to cover the following:

1. Given - some precondition
2. When - some action executed by the function that you’re testing
3. Then - the expected outcome

This is also known as AAA (Arrange, Act, Assert).

Jest offers describe function to help structure your tests. Use describe to group together all tests that belong to one functionality. Describes can be nested, if you need that. Other functions you'll commonly use are beforeEach or beforeAll that you can use for setting up the objects you're testing.

If your test has many steps or many expectations, you probably want to split it into multiple smaller ones. Also, ensure that your tests are completely independent of one another. Each test in your suite must be executable on its own without first running some other test.

Unit tests cover the smallest parts of code, like individual functions or classes.

The great thing about unit tests is that they are quick to write and run. Therefore, as you work, you get fast feedback about whether your tests are passing.

Sometimes, when your tested objects have external dependencies, you’ll want to “mock them out.” “Mocking” is when you replace some dependency of your code with your own implementation.

Jest comes with support for mocking from function level all the way to module level mocking.

In integration testing, real individual units are combined (same as in your app) and tested together to ensure that their cooperation works as expected. This is not to say that mocking does not happen here: you’ll still need mocks (for example, to mock communication with a weather service), but you'll need them much less than in unit testing.

For testing React components, there are two things you may want to test:

• Interaction: to ensure the component behaves correctly when interacted with by a user (eg. when user presses a button)
• Rendering: to ensure the component render output used by React is correct (eg. the button's appearance and placement in the UI)

There are several libraries that can help you testing these:

• React’s Test Renderer, developed alongside its core, provides a React renderer that can be used to render React components to pure JavaScript objects, without depending on the DOM or a native mobile environment.
• React Native Testing Library builds on top of React’s test renderer and adds fireEvent and query APIs described in the next paragraph.

Avoid testing implementation details like props or state—while such tests work, they are not oriented toward how users will interact with the component and tend to break by refactoring (for example when you'd like to rename some things or rewrite class component using hooks).

React class components are especially prone to testing their implementation details such as internal state, props or event handlers. To avoid testing implementation details, prefer using function components with Hooks, which make relying on component internals harder.

Snapshot testing is an advanced kind of testing enabled by Jest.

A "component snapshot" is a textual representation of your component’s render output generated during a test run.

With snapshot testing, you typically first implement your component and then run the snapshot test. The snapshot test then creates a snapshot and saves it to a file in your repo as a reference snapshot. The file is then committed and checked during code review.

In end-to-end (E2E) tests, you verify your app is working as expected on a device (or a simulator / emulator) from the user perspective.

This is done by building your app in the release configuration and running the tests against it.

E2E tests give you the highest possible confidence that part of your app is working. The tradeoffs include:

• writing them is more time consuming compared to the other types of tests
• they are slower to run
• they are more prone to flakiness (a "flaky" test is a test which randomly passes and fails without any change to code)