Research and integrate/develop base facilities for asynchronous integration tests for SDK #655
Description
Although Android provides a wealth of testing facilities, the specific combination of integration testing and Android Service in asynchronous manner presents a lot of obstacles:
- Haven't found a specific framework for that. Even though there are lots of frameworks out there for UI Testing (Espresso), Unit Testing (AndroidJUnit together with potentially mocking framework or roboelectric, which by the way seems great for Unit Testing) and ways to do IT with AndroidJUnit they are not enough. We have already covered UI Testing using Espresso and are not yet in realm or Unit Testing. We need to be able to test our APIs top to bottom.
- There are asynchronous frameworks out there, like Awaitility, which I tried but there are synchronization issues that are tough to work around:
- For example to be able to test RCDevice (which is a service) you need the Tests (that by default don't run in the UI thread) to have a Looper, so that communication with Signaling thread can be initiated.
- Running the test in UI thread doesn't help as it messes with the ServiceTestRule that is required to test the Service properly
- Adding a Looper to the testing thread works, but once you do that you need to start the event-loop and then you lose event management that Awaitility provides.
So the direction we 're currently investigating is to use Android building blocks like Looper, Handler, etc which are easy to use and super efficient and use the sole Looper to receive both events from signaling thread, as well as events related to testing. So for example when testing RCDevice.initialize():
- We can set a timer to say 10 seconds as a time out and when RCDevice.onInitialized() callback is invoked we can check if all good and if so mark the TC as success.
- If it hasn't been called or there is an issue the TC is failed
In any case what an asynchronous framework mainly provides us is a way to notify us when a condition is met and timeout if it doesn't, the rest of the handling is outside its scope and the job of the TC testing code.