Consider testing the native part of the library (e2e + unit)

[Fr33maan]

Describe the Feature

Actually the issue tracker is full of bugs, giving context to reproduce can be tricky and very special versioning issue arise.
This library rely on many other in order to share, it's tricky to write automating tests but I'm pretty sure it's a nightmare to do a complete manual testing of the app considering the number of packages and cases.
But social sharing is very important for any app with commercial goal so a solution need to be found.

It's pretty annoying that in 2020, maintainers of this package need to fix bugs like base64 encoding or Flipper version AFTER a release because testing such a complex library is a very complex task.

Possible Implementations

Right now I'm working with UI Automator to make end 2 end tests. While it's pretty doable on a simulator or real device I own, it's a challenge to automate this in a device farm (which is the goal because we need to test many configurations).
Here is the list of challenges and questions I would like to discuss with you.

Writing test itself is not so hard when writing for one device, I'm pretty sure there will be issues with different devices, ios/android versions, etc...

1. Install apps
   On android it's doable by uploading apk directly on devices (IG, messenger, facebook, whatsapp, etc...).
   For iOs I have no clue how to install apps on devices.
   I also have no idea atm how to configure those apps without a carrier. Whatsapp for exemple require a mobile number.
   Maybe we can upload configuration files on the devices ?

2. Test on simulators:
   With github actions, it will be free to test for android and ios. It's my next step.

3. Test on real devices:
   As you all know, when you launch in prod, some specific issues arise related to manufacturers. We need to use devices farms.
   Device farms are damnly expensives. Now Github is a microsoft property and considering the high number of stars for this lib, it might be possible to ask them for app center credits.

Related Issues

• install apps on iOs sim and devices
• install pre configured dependant apps
• device farm cost
• exploring more devices

Tools

• JUnit - Espresso
• UI Automator
• AWS Device Farms / Firebase testlab / AppCenter Test

[MateusAndrade]

Hi, @Fr33maan I agree with, currently, we are planning to port the project to TS on #805 to accomplish better support on the APIS, but without tests, we would still a lack on the tests of each PR.

Now we don't have any native/js tests implemented, but we are able to run both ios and android build on CircleCI. Also, we have support to apply Detox E2E tests on our CI since we can build iOS and Android. 🚀

But we have some challenges to cover the application with tests, personally I think using an E2E would be great, but to achieve that we will definitely need some changes in our native implementation #741.

I would be happy to discuss that and see other examples to implement that, one package that currently uses an E2E approach is datetimepicker, maybe this can be a start point to implement that approach on rn-share.

[Fr33maan]

Hi @MateusAndrade, while I see the build on CircleCI as a good first step to insure code quality, I would like to speak about testing only.
The lib does not appear to have critical bugs on the JS side, even if writing unit tests on the JS side is obviously a good idea, I'm purely speaking about compatibility issues with other apps on both android and iOS.
If we look at the issues right now, 90% of them are happening on the native side.
But if you want to speak about unit tests, yes, unit testing the native part of your module would be a great thing for all the contributors team.

---

The issue you are referring about testID is not a big deal for us. You can overcome the lack of testID by targeting elements with text. It's what I'm doing right now to test the lib. I use UI Automator which is pretty well working actually.
You can see it there -> The test file on my repo

---

If you look at what I've done, I have serious doubt about compatibility between different versions of android. For exemple, on the gmail test, I have to close the keyboard and then press back (2 times, don't know why), not sure if the keyboard will be opened on another android version / manufacturer. Only tests on farms will tell the truth.
The tests are slow to run, around 8 seconds for each unit. Comparing to jest unit tests, it's really huge.

It's tedious to develop such tests but the reward is enormous, no more incompatibilities.

The actual goal for my end to end tests is pretty simple, displaying on the screen the native libraries (gesture, webview, udp, linear-gradient, share) to be sure they are not crashing the app.
While it's pretty straight forward for most of the lib I use, react-native-share is a very special flavor because of the dependencies on other applications.

---

I think the first thing to discuss here is the strategy to install preconfigured apps on both android and iOS. I'm not an expert in native, much more in JS, but I would be happy to do some researches if I have some help.

[github-actions]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions. You may also mark this issue as a "discussion" and i will leave this open