Fork me on GitHub
#cljsrn
<
2018-04-13
>
manu12:04:40

Hi! How do you test your react-native app? Thx!

mfikes12:04:30

@manu Are you curious about CI tests, or just testing in general?

manu12:04:05

At the moment I'm doing all my test manually.. but it is quite annoying and I'm sure there is more productive way to do it..

manu12:04:04

I've no idea how to test a react-native app

manu12:04:10

what's the best practice?

manu12:04:41

should I create a test folder and write there my test?

mfikes12:04:18

@manu I've ended up writing at least tests for view generation code that can run directly in jsc. If you look at https://facebook.github.io/jest/docs/en/tutorial-react-native.html you could argue that testing generated Hiccup (in the case of using Re-Frame), is more flexible than diffing a file.

mfikes12:04:21

Others have gone as far as to use systems that automate pressing buttons, etc.

manu12:04:58

@mfikes but can I write in clojurescript?

mfikes12:04:57

Yes, I've been writing my tests in ClojureScript, using the facilities in cljs.test

manu13:04:24

ok I'll try! thx! πŸ™‚

vikeri13:04:07

@manu We’re running our tests in nodejs, but mainly testing logic and not components (spec + re-frame = zero component issues)

vikeri13:04:23

@mfikes testing could also be a relevant topic to fund

jeaye17:04:50

@manu I've recently set up some initial integration testing, using Appium and http://webdriver.io: https://github.com/OkLetsPlay/lets-bet-integration-test

❀️ 4
jeaye17:04:41

Basically, integration testing works on the production app, just as a user would. You can script sessions, saying where to tap/swipe, what to type, and what to expect to be visible and where.

jeaye17:04:21

Nothing fine-grained, but it's a good automated way to navigate through the app and make sure the full system (front-end and back-end) is working properly.

jeaye17:04:03

We combine this with unit testing (which is not open source yet). I'd like to get something like jest's snapshots going as well, but that'll have to be made from scratch, since jest requires metro bundling, which takes several minutes for our app and is a real pain.

pesterhazy18:04:55

@jeaye thanks for the report

pesterhazy18:04:53

Am I right in understanding that http://webdriver.io is for testing the Web frontend and Appium for the Mobile frontend?

jeaye18:04:14

@pesterhazy Sort of. Appium is the back-end which talks to the emulator. wdio is the front-end which provides the API for interacting with the UI. There are a few options for front-end libraries, with mostly the same UI, but they will all talk to Appium.

jeaye18:04:02

Finding docs for getting all of that going, especially with ClojureScript, was not straightforward. I have some blog posts on it, as well as using promesa for the async tests, in the works.

pesterhazy18:04:42

So you need http://webdriver.io even when you're testing an iOS/Android app?

pesterhazy18:04:57

I thought it was, like Selenium, for talking to a browser

jeaye18:04:17

An example from the Appium docs, showing different front-end usages (click Javascript to show the relevant code sample): https://appium.io/docs/en/commands/element/actions/click/index.html

jeaye18:04:11

@pesterhazy wdio speaks a protocol. The webdriver protocol. Appium is a server which implements that protocol for mobile devices instead of the web.

jeaye18:04:18

It also extends upon it to provide a bit more.

pesterhazy18:04:25

Ah now I get it, Appium is sort of like Selenium for apps

pesterhazy18:04:31

Hence the latinate suffix

pesterhazy18:04:42

And they speak the same protocol

jeaye18:04:54

You got it.

pesterhazy18:04:14

Ok cool. Have you tried iOS as well?

jeaye18:04:31

Nope, but it's supposedly easier. We're only on Android right now.

jeaye18:04:53

The tests run nicely in my Android emulator, even in debug builds with figwheel enabled.

pesterhazy18:04:40

I should try it. Last time I used Kif, which didn't work very well.

jeaye18:04:23

If you're running integration tests, and you use spec, I think you should absolutely be using Orchestra. It's the perfect time to make sure all of your data is the correct shape as the "user" uses the "production" app.

jeaye18:04:42

So, basically, our integration test builds are the prod build + intrumentation.

pesterhazy18:04:38

How often are the tests flaky during CI, if I may ask?

pesterhazy18:04:19

If you need to rerun CI 20% of the time, it almost negates the benefits of the 80% of cases where things work fine.

jeaye18:04:27

We're not yet running these in CI. I've just been setting them up in the past couple weeks and I'm trying to sort out how to best orchestrate two devices using the app together (since our app is about connecting people to challenge each other).

jeaye18:04:58

When running the tests, I have not yet seen spurious failures. Running on a CI machine, all the damn time, will help bring those out though.

pesterhazy18:04:13

Right. Probably a good idea to automate the hell out of this as soon as possible

pesterhazy18:04:38

Tests you need to run manually provide less value

jeaye18:04:22

Yes indeed.

jeaye18:04:58

I'm really looking forward to being able to automate full app playthroughs, between two users. Especially on a CI machine, though, which can likely only run on Android emulator, that may be tough to pull off.

pesterhazy18:04:04

Yeah that sounds tricky

jeaye18:04:24

Could make a service behind an API (so a second "device" isn't needed) for starting fake client sessions, changing bets, chatting, etc, but that service would have to have its paws in the internals of the back-end to make things work. It'd be the easiest, but it would break with internal changes.

jeaye18:04:03

Also means I can't test both ends at the same time.

pesterhazy18:04:41

Sounds like manual testing is the best option πŸ™‚

jeaye18:04:30

I disagree, at this point.

jeaye19:04:22

Manual testing the whole app, after every update, is not only a big time sink, but a big money sink, in terms of paying QA personnel (who're human and make mistakes).

jeaye19:04:11

It can be automated well, I think; it's just not an easy problem. At this point, it still seems worth the time. That may change.

pesterhazy19:04:17

It's also possible to get lost in the attempt to automate testing. Hopefully not the case for you!

pesterhazy19:04:39

I'm wishing you luck πŸ™‚

pesterhazy19:04:13

Even just a simple "golden path" smoke test will already catch a ton of errors

pesterhazy19:04:27

You can always extend that later on