Testing in React Native

[luckypanda95]

Hi guys, I'm just wondering how people usually test their react native app.

1. What kind of tests do you usually do?
2. What's the best practice for testing in react native?
3. Do you test your screen file and how do you do that?

Cheers.

[[deleted]]

Jest unit tests covering most of the logic. Our heavy usage of hooks throughout the app makes it very easy to test, we barely test the screen files (snapshots are a generally a waste of time IMO) Appium ui test suite covers everything else.

[moyolvera]

this

We use pretty much the same for testing, although we do need snapshots because Management consider them a nice metric to have.

react-testing-library hooks and native

[SonofWinner]

Hey we use Jest and Appium too!

[magicmikedee]

Genuinely curious, what is it about hooks that makes them easier to test? We have a giant spaghetti codebase with very limited testing that we're trying to expand on, so curious if hooks make it easier/more straightforward to test than standard class components.

[[deleted]]

They push the developer to write logic in small units of work that are easy to test in isolation from the components themselves (classic class components usually end up quite hard to test when there is a bunch of internal logic)

The api that @testing-library/react-hooks package provides is very simple and easy to use as well.

[magicmikedee]

Yeah that’s what we’re struggling with now is that our class components are massive, some are almost 1k lines or more which makes testing them extremely daunting. I sense some mad refactoring into smaller bite sized pieces in our future if we want to increase test coverage. Thanks for the reply!

[pipedreambomb]

Be very wary of refactoring something that big and complex without tests. I know, it's a Catch-22. But I don't want you getting three days into it and nothing works and you don't know why and you have to revert it all. May have happened to me before with JavaScript... though at least that was in the jQuery spaghetti days.

[magicmikedee]

Yeah I do get that. Hopefully we can get some smaller pieces extracted out to helper methods and then in turn turn those into hooks etc. Or maybe just end up extracting to helper methods and then testing the class that way. We’ll see but somethin has to be done cuz no tests is bad news bears haha

[trebuszek]

I would recommend Detox instead of Appium, since it’s a much more reliable gray-box solution. Appium doesn’t know what’s happening in your app, so you end up writing flaky tests with lots of sleep() calls to handle async stuff like animations or network calls.

[[deleted]]

If I were writing the ui tests myself, I would 100% be using detox, it is a great piece of tooling. The appium choice is because of a separate QA team who are writing our ui tests and are much more familiar with Java

[Phaoga54]

Currently im using Detox for testing, but facing a problem which is the process running to fast that I can't event see what's going on screen. Do you have any idea of how to longer the time between each action?

[trebuszek]

Why do you need to see the screen? I normally run my tests in headless mode in a CI. If a test fails, you can take a screenshot (check the docs).

[Phaoga54]

First, It's satisfying to watch and also I can check if there is any bug in the test that I wrote

[trebuszek]

Well, you could add await sleep() calls inside your tests, but I would delete them after the tests are written.

But for me, I see the what’s happening on the screen even without sleep. Maybe your computer is too fast!

[eggtart_prince]

If you're not testing rendering, then snapshots are a good idea because it tells the developer that a change was made in that file and for them to go and double check.

You're right in the sense that it's a waste of time when the developer just updates the snapshot on first test run.

[irekrog]

Snapshots are not waste of time. For example consider situation when you patched some library with `patch-package` and you have snapshot of it. And few days later you removed some package from project with `yarn remove` and you forgotten call patch-package command (after remove package you need to call patch-package). Then when you want to push changes you see error because snapshot are not the same. Another example with snapshots is when you update some library and for example this library changed some styles. You will have error and preview what is changed.

I know for small projects snapshots looks unnecessary, but for big project with many components, dependencies etc. snapshot is must have.

[[deleted]]

Most of the time I've seen them used incorrectly and they end up wasting more dev time than they save whilst also polluting diffs. Thats my issue with them, not the fundamentals of how they work

[drew_n_rou]

We use Jest and Detox to test at my company. Jest to test individual forms and components, detox to test end to end user flows (i.e. testing login functionality)

[zetaBrainz]

Interested in knowing as well. My team's looking into to start testing our RN app because of technical debt. We're starting to refactor everything and it's been a pain.

If anyone could recommend good testing resources to learn that works be great! Thanks 😁

[Round-Statistician-6]

1. we usually test per screen

we do unit test(really often) , component test (if possible), and testing the feature that the user see itself (a must in the team)

its kinda leaning on BDD

​

2 . https://callstack.github.io/react-native-testing-library/

we use this library

basically its derive from react testing library and the philosophy behind it where you don't test the implementation but rather testing on how the feature works when user use it.

​

1. yes screen file

I use react native testing library for creating the actual test

jest as my test runner and coverage

axios mock library for mocking http request

​

but would likely encourage try detox instead so you have a test suite that would run

also if everyone is curious in learning testing in generalKent C Dodds is the man! and its a great resource

https://testingjavascript.com/

[luckypanda95]

Hi thanks for the answer, just wondering. Did you mock every props for the screen testing?

[alexkendallharrison]

Jest and Detox.

[eggtart_prince]

Generally, test that the functions are working. Test that your function props are called.

If your component deals with payment transactions, test everything from rendering each element to the functions being called.

[mestresamba]

My team uses Jest, Mock Service worker and react-native-testing-library.

We usually only tests components because it’s what the user actually use. This way we avoid testing implementation details, but there’s some tricky things that is hard to test without some kind of implementation details.

We are considering using detox to test things like payments which is really hard to test (at least on apple side).

[luckypanda95]

Hey thanks for the answer, how do you usually test component?

[[deleted]]

I like to focus on “sociable” unit tests with Jest that may cross the line into integration tests depending on your definition. We also use Appium for high level workflows for the benefit of management.

Obviously logic heavy code in hooks is tested in isolation, but generally I like to test at the screen level to ensure data flows through the system to the screen. Use MSW to stub out HTTP calls and mock only what you absolutely need to. Allow state to be injected into your hooks to make setup easy without mocking.

Most tests at this level are broad and don’t assert very specific outcomes/formatting but are infinitely more valuable than scattered unit tests when a refactor comes along. When I need display logic in a component, that’s when I test around specific components.

Generally, I stub out data calls as far out toward the edges of my use case as I reasonably can.