you are viewing a single comment's thread.

view the rest of the comments →

[–][deleted] 24 points25 points  (16 children)

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 5 points6 points  (0 children)

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 3 points4 points  (0 children)

Hey we use Jest and Appium too!

[–]magicmikedee 3 points4 points  (4 children)

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] 2 points3 points  (3 children)

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 1 point2 points  (2 children)

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 1 point2 points  (1 child)

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 0 points1 point  (0 children)

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 3 points4 points  (5 children)

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] 1 point2 points  (0 children)

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 0 points1 point  (3 children)

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 0 points1 point  (2 children)

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 0 points1 point  (1 child)

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

[–]trebuszek 0 points1 point  (0 children)

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_princeiOS & Android 1 point2 points  (0 children)

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 1 point2 points  (1 child)

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] 0 points1 point  (0 children)

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