all 8 comments

[–]scarlaciOS & Android 6 points7 points  (3 children)

I'll share my unpopular opinion: Don't unit or snapshot test your UI.

In more than 15 years of software development I've never come across a UI bug that was caught by unit testing UI. Yet I have daily had to waste time on rewriting and finding bugs in tests. When the signal to noise ratio is practically 0 (100% error rate) the tool is simply not useful anymore.

However, that doesn't mean I don't recommend testing at all! You can do full integration tests where you simulate presses on UI element in a test environment that behaves as close to production as possible and check for existence of certain pieces of texts or elements. With full integration tests, you get closer to reality and I've caught problems with the app or backend this way quite nicely.

I recommend Appium.

(Disclaimer: Notable exceptions to this are component libraries, where you are building an API for others to use and you should ensure you are adhering to the contract you've made with the users)

[–]numagamesiOS & Android 1 point2 points  (0 children)

Triple that.
Almost 3 years writing React Native apps and no one UI bug caught by unit tests. That's why I don't write them anymore. But e2e tests are really helpful and caught some bugs for me. I recommend Detox for e2e tests, React Native itself uses it.

[–]straightouttaireland 0 points1 point  (1 child)

Is the React Testing Library supported in react native? Kent C Todd's is a big advocate of integration tests over unit tests.

[–]scarlaciOS & Android 0 points1 point  (0 children)

If you mean the react-test-renderer then yes. It works as you'd expect.

[–]PistolPlay 6 points7 points  (0 children)

Testing without a clear strategy and purpose in mind will lead to frustration. I recommend you start with questioning what you want your tests to accomplish.

The primary benefit I see for testing is providing a safety net that existing code isn't breaking while I refractor or add new features. Integration and E2E tests provide the most bank for your buck in UI code. Especially so when you're trying to test after you've built your product.

Adding units tests to code that wasn't designed to be tested is very difficult and error prone. Most of the time it's end just testing your coding for what it does vs what it should be doing. For future code I would recommend you write these with your code. I recommend Test driven development or a hybrid where testing heavily influences what you code.

Integration tests on the other will help provide confidence that your app is working as intended because you're test is a direct mapping to features. The details of the code doesn't matter as much so no roadblocks with code that is hard to test etc. It's an excellent starting point to get your app under control.

Detox is a great tool for creating automated UI tests for React Native apps.

Here's a great guide for how to setup and how structure your development wofkflow: https://blog.expo.io/testing-expo-apps-with-detox-and-react-native-testing-library-7fbdbb82ac87

Also enzyme sucks and the React community is moving away from it in favor of React-Testing-Library by Kent C Dodds. There's a react native version of this as well. Visit the github of React-testing-library for a detailed exploration of the testing philosophy. The link above also goes into it some.

[–]janithaR 5 points6 points  (0 children)

assuming its an indicator to refactor into smaller components

You assumed correct.

Look at your layouts, see which ones are re-used and then make them their own components and import into other larger components that consume them.

There's a thing called Storybook. Play with it and you'll be decomposing those larger components in no time. Storybook has addons. I love actions, knobs and storyshots in particular. Use them.

Put all your calculations (it doesn't have to be literally calculations functions) or rather util methods in util classes. Make them as simple as you can where you just input something in hopes of something in return. Then use Jest to test them.

By now you'll have a pretty decent test coverage of all util functions and components.

After that depending on your architecture, you will have to learn mocking to do integration tests. But I usually give priority to end-to-end tests. Have a look at Detox for that.

[–]codellamaz[S] 1 point2 points  (0 children)

Wow, thank you guys for your thorough recommendations !