While moving from Robotium to Espresso, we had a few issue to make the tests pass. Here is a short description of them with some solutions.
Click events become long click events
This is an due to the way Espresso implements click events. By providing
pressBack() as rollback event to the click event most issues could be resolved. As described in http://stackoverflow.com/a/35254071/243599
There is no test method to verify an activity result
For this we created a
ActivityResultTestRule that provides access to the activity result as well as some method to verify the code and the result data. For the result data the Espresso-Intents matchers are also useful. The main inspiration was taken from http://stackoverflow.com/a/5759318/243599
Things in the background are not reported to the tests (add IdleResources)
DirectoryScanner was adjusted to report back to
IdleResourceListener when it has finshed.
Enter key event fails when activity is finishing
Espresso sends an down and up event when executing
click(). The up event fails when the activity was finshed inbetween. As a solution a down event action was created.
UI animator needs a manifest for androidTest source set
UI animator needs SDK 18, hence we need to add the following line to the Android Manifest used for `androidTest:
Creating the xml file was easy, finding the correct location for it was not obvious because the source set definition (
manifest.srcFile) was ignored by gradle.
For the current non-standard directory layout it is required set the root of
androidTest and then use the standard structure. This allows gradle to pick up the manifest file.
Newly created directories and files are not shown
As the activity has already started and the scanner is not refreshed the newly created directories and files are not shown. In order to handle these files, the creation code has been moved to the static file
Activities in androidTest can’t be used as test activities
Activities (even when added to the instrumentation manifest) can’t be used as a starting point for tests because the instrumentation element of the manifest is generated by gradle with the application under test as target. During executing the instrumation is waiting for activities of the application, not the instrumentation. Using the same process name does not make any difference.
Sending keys (like enter key) while soft keyboard is open fails
Typing text via Espresso might open the soft keyboard and hence covering the activity. Thereafter, it is not possible to send a key event because the soft keyboard is overlaying the window, resulting in an
Injecting to another application requires INJECT_EVENTS permission. Adding
closeSoftKeyboard() helped here.
OpenIntents Team CODING