If you’re currently developing the next great app with react native or already have an app in the store, you’ve probably thought about testing your app. So here’s the thing, most developer teams love the idea of testing their modules, screens and components but it rarely happens.
We just can’t find the right time, in some cases we don’t have the knowledge, we’re not sure how to “Sell it” to the client or convince the stakeholders. We’re wondering what the consequences will be, will writing more tests slow down the team’s velocity?
Well let me tell you something, if you skip the testing part it will probably be “tested” by your users and backfire on you. You’ll find yourself dealing with more bugs, unhappy customers and an exhausted support team.
“I’m loving my tests the most when they’re failing”
Don’t get me wrong, it’s not all sunshine and roses. Testing does come with a price (literally), but if you do it correctly, at some point, it will save your ass.
So if you read until here, it means that I’ve managed to convince you, but where should you start?
Establishing good habits
Shove the code coverage in the pull request (PR) reviewer’s face. Define guidelines with the rest of your team, for example- what is the bare minimum test percentage coverage etc. You can achieve this with tools like: Sonarcloud, Sonarqube or Codacy.
“The more your tests resemble the way your software is used, the more confidence they can give you”
Gaining knowledge and finding the right tools- there are a lot of testing frameworks and tools out there. It may be overwhelming in the beginning and this is why I’m writing this to begin with.
After experiencing many methods, libraries and hacks I can pretty much say that this is the easiest, fastest to learn and configure, and the most stable testing stack for testing your react-native (RN) app.
The stack consists of:
React Native Testing Library– which has a list of RN testing utilities, the library (lib.) encourages developers to write tests that resemble the way software is being used. This lib. enables rendering of RN components, interacting with buttons, text inputs and navigating between screens. This makes E2E testing painless, without tedious configuration and resources that are needed to run an emulator in order to test your app.
React Hooks Testing Library– has testing utilities that makes it possible to test hooks independently (without using it in a component). Although a good practice is to test your hook where in use.
Prioritizing test subjects
Where to start? start with the most important modules, screens, utils and the core logics of your app. This probably means your state management part of the app or any other place where you’re fetching data or making external calls. From there move to hooks, screens and any other piece of core util.
Real life examples
- Clicking buttons and asserting onPress’ outcome.
- Filling a simple login form and asserting successful submission.
- Custom hook testing (number of alternatives).
- Mocking fetch calls.
- Mocking navigation through screens(react navigation v5).
- E2E feel due to real navigation throughout screens.
- Handling and mocking providers.
- Mocking external lib.’s components.
- Mocking and interacting with RN’s Modal component.
- Handling with a screen with RN’s FlatList component.
- Using MSW to mock api calls and handling loading/errors.
To sum up, nobody is born a tester, and just like everything in life, starting with it might be scary. Eventually you’ll get used to it and you’ll write tests better and much faster.
Take the time to run this repo I’ve made and play with it, honestly it’s a great starting point and I’m updating it constantly. And of course if you have any questions or wanna say hi, email or follow me on Twitter
Interested in growing your developing skills in an international team? We are always looking for new talent! Check our website or email our HR professional Jonna at email@example.com.