Skip to main content

Writing Performance Tests

Writing (good) performance tests for Reassure​

tip

For an example of writing a reassure test, make sure to go over the latest guide at https://github.com/callstack/reassure#writing-your-first-test.

Instead, this section is focused on the thinking behind writing a "good" performance test.

1. Mocking​

Mocking is particularly important in writing a good performance test. These are all side-effects in our app that should be consistent across our sample tests. Required mocking includes modules, libraries, store states, navigation states, request data, and so on. The more precise mocking we can achieve, the more concise measurement we can acheive as an end user would experience.

2. Controlled Scenario​

Then the scenario should be modelled precisely to reflect the scenario in real devices, all side-effects should be considered including when and what to expect and should be waited for.

3. Continuous Testing​

Now assuming the acceptance criteria of the feature hasn't changed, the very same scenario of the test should not require further modification after it's committed, this is similar to a black-box test. Therefore, upcoming MRs with code changes that would affect the performance will be automatically picked up by the CI Pipeline jobs, and validated.

Example​

Using Reassure​

Often there's a need to run a particular test for debugging or other purposes. We can do this by modifying the default jest runner argument to only include the file we want to debug. For example,

TEST_RUNNER_ARGS='--testMatch "<rootDir>/ladbrokes/app/screens/__tests__/LadbrokesHome.perf-test.tsx"' yarn reassure