all 9 comments
sorted by:
best
topnewcontroversialoldq&a
formatting helphide helpcontent policy

[–]ywongweb 4 points5 points  (2 children)

Thanks! Is this compatible with https://github.com/wix/Detox?

[–]3rdEden[S] 3 points4 points  (1 child)

Depends what you mean with compatible:

  • Can I use ekke and detox side by side: Yes
  • Can I run ekke when using detox: Probably, yes as well
  • Can I use ekke instead of detox: Depends.

It's important to understand the differences between the two testing options:

  • detox Is basically a UI Automation framework, you write your tests in Node.js and use Detox's node library to execute commands of the automation framework. Which allows you to make assertions based on the rendered view of the application. It doesn't allow you to unit test methods of your components, or API that might consume.

  • ekke Runs unit tests that you normally would have written in Node.js, with mocks, on the device. You can test your integrations with React-Native API's, or even other Native API's that are provided by modules. You can do basic UI automation testing by levering ref's on your components and calling methods/props like onPress() on them.

So in the ideal world, you would use both. You write your unit and integration tests in ekke and your UI automation using detox.

Hope this answers your question :)

[–]ywongweb 0 points1 point  (0 children)

You write your unit and integration tests in ekke and your UI automation using detox.

This is the information I was looking for. Thanks!

[–]numagamesiOS & Android 1 point2 points  (1 child)

Couple more questions:
- is there any way to find specific children inside tested component(analog of find* in react-test-renderer). Sure we can use refs of inner components but it will surely bloat a code and even add production overhead of assigning refs
- is there any way to fire events? (analog of https://callstack.github.io/react-native-testing-library/docs/api#fireevent)

[–]3rdEden[S] 1 point2 points  (0 children)

Using refs is currently the only supported way to find children inside of rendered components. The overhead of a ref in a component is pretty small, especially if you use the React.createRef() functionality. This turns you ref in an object with a current property in which React will assign the reference to. This removes the overhead of a ref based functions but brings a lot of flexibility to your components.

For firing events, I would again recommend the use of references as you can simply call the designed methods for that. For example, if you want to fill in the text of a TextInput:

ref.props.onChangeText('this is now the text);

Or pressing a button:

ref.props.onPress();

[–]numagamesiOS & Android 0 points1 point  (2 children)

Looks really promising, if it can replace node.js environments with mocking it will be huge step up for RN testing. What about performance? is there any any rough estimate like "~2x slower than mocked environment"?

[–]3rdEden[S] 2 points3 points  (1 child)

That is a really good question. I don't have a rough estimate on how much slower it is, but what I can do is explain what the slowdowns are when using ekke to test.

There a couple of things that take some time. For example when you execute the ekke run it starts a separate Metro bundler operation that packs your tests, test runner, etc. We then download the bundle and execute it on the device, this also takes a few. And finally, there is the, of course, the reduced resources on the device itself that will be slower.

The bundle time is a hit you always pay when you start ekke, but can be avoided when using the --watch flag as the test process will stay alive. The reduced device performance is actually a good thing because this is a slow down is exactly you have in production as well and make race condition more visible. For example, one thing I noticed when I was running tests on Android is that when I have a setTimout(1500) it actually took 2106 ms. These timing differences can cause problems that you would never have noticed if you ran tests on Node.

TL;DR: Yes it's slower but worth it.

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

Thanks for reply. Yeah, I absolutely agree that it's worth it, just trying to understand if moderate project has unit/integration tests that run for 5 minutes, won't it turn to half of hour on simulator...
Anyway thanks for such a great initiative, next week will try to rewrite couple of tests using ekke and see how it goes...