unit test cases redesign

[graychan]

The app has a few asynchronous tasks and a local service. These tasks and services create concurrency that the Android Unit Test instrumentation does not seem to isolate well. As a result, the unit tests demontrate some race conditions. For instance, although the instrumentation observes that an activity has already been loaded; however, the activity is not ready to perform any user operations as an asynchronous task is still running and loading UI elements. On a fast emulator, such as an Atom emulator, these race conditions cause less problems than on a slower emulator, such as an ARM emulator since the asynchronous tasks and the service are likely to run to completion on the faster emulators before the instrumentation gets a chance to run the statements whose preconditions are not met.

At present, we use a naive approach that whenever we observe potentially a race condition may occur, we let the thread sleep for a couple of seconds. This is not a good approach. First, it makes unit tests run slow. Second, when more unit tests are performed on an emulator, the app will have more experiments to load and the sleeping time should be longer; however, it is difficult to predict how long the sleeping time should be.

In future milestones, we may be better off to redesign the unit test cases.

[SagarPandit01]

This issue was moved to sysnetlab/SenSee#9