Structuring Android UI tests

There are a lot of possible ways how you can organize UI tests on your project. The final implementation depends on many factors. I want to share the solution we use on our project, and hopefully, you will find it useful to apply to yours.

First of all, let’s define the main requirements for our structure

• Support testing both: a standalone screen and flow of several screens
• Easy to understand, write and support by QA automation or Developer

We will define the list of possible “actions” that we can do on the screen. On our Login screen it can be:

1. check initial state
2. type “email.”
3. type “password.”
4. click the “submit” button
5. check validation errors

Each of our “action” can use multiple views and espresso functions. See the example:

We can simplify it by using our Kotlin extensions (link):

Now we can use our actions to test the Login screen:

And reuse it to test the login flow starting from the home screen

As you can see there is nothing difficult or new here but it perfectly fits us:

1. They look “clean”. You can “read” your test cases and don’t focus on the implementation details. Even QA who doesn’t have Android experience can understand them.
2. It’s easier to make updates while refactoring or adding new functionality
3. You can reuse most of the “actions” related stuff in different test cases and focus on the tests details rather than framework stuff

I’m welcome any feedback or questions.