Android AutoTest Part 1.3: Good Test Code with Good Test Flow
Tags: Android Autotest, Mti, Android Espresso, Technical, Android

If you are new with Espresso FW, please read my first Story here:

In this section, I will guide you on how to structure your test code and how to do the flow of UI testing efficiently.

Firstly, pls take a look at the UI Testing Flow here:

We have 2 ways at the first initial, TDD or Not-TDD.

With the TDD way, you prepare everything and UI Test Code before you actually write the real code.

With the Non-TDD way, after you finish the features, you start writing the UI Code Test.

With a recommendation, you should follow TDD first

When developing a feature iteratively, you start by either writing a new test or by adding cases and assertions to an existing unit test. The test fails at first because the feature isn’t implemented yet.

But in this topic today, we do from Feature-Done first

1. Create Scenario Test Cases:

It’s important. We should write the test code base on the test cases. Our TestCode should do steps by steps like the user’s behavior and follow a scenario. The Test is good or not is totally based on the quality of the scenario good or not. With a good scenario, our Test Code will totally cover all features with the user’s behavior view.

Here is 1 example or Scenario Test Case:

This test case scenario is written base on the example application described at here: https://tuanna731985.medium.com/android-autotest-part-1-1-make-friend-with-espresso-cc5708815e9c

Let take a look back on our example:

Our test steps of the scenario are:

Install app -> Open app -> Main screen: Input text “Hellow World!” to EditText. Press button “Change Text”: Press button “Open Activity And Change Text” Press Back

At each step, we have an expected result.

For each step, we mark the ID for each step. This ID is really important. This will help us mapping between the test code and the test case document.

In the Scenario Test Case document. We can track which step is done by AutoTest. And we can calculate correctly how many percent of the coverage that AutoTest can cover on total test cases. It’s important for tracking the quality of the Test Code.

Done, First step (Create Test Case)

2. Structure Test Code

A good test code should have a good structure. If don’t, you will get many trouble in maintenance the test code.

Firstly, structure of the Test Project first:

We will create a package containing classes for representing the “UI Screens” of application “screens”.

Package for test case “test case”: this will include all scenarios that we wrote in the Scenario Test Case document.

Package for customization the Espresso lib “custom”

Package for some utility classes “utils”

Let talk more deeply about the “screens” package. The screen class is represented for 1 real UI Screen. In a good way, we follow the Page-Object pattern:

In this story, I will guide you in a simple way:

In 1 specific UI (screen or dialog), we will have 1 class for representing that screen UI. In this class, we write all the necessary methods for interacting with that screen UI.

Let look at our example, the Top screen. We have some components on a screen. Here is our code class for representing that screen will be looked at below:

We will have the mapping between the UI and the code is:

viInput(): represent for EditText

viChangeText(): represent for Button Change Text

…

fun inputText(xxx): will include multi actions for interacting on components on screen.

fun submit(): will get button and perform click action.

— — —

In brief, instead of we write everything in the main test method, we structure them to screen by screen and the screen will be represented for properties and functions of all components on the screen.

Let see the mapping in this picture:

After structure the test code for all necessary screens, we start writing the test code follows the test case as below step

3. Update Test Code Follow The Test Case

Let see our test code that followed the test case but without structured:

Can you see which test code line is represented for which step in the scenario test case? It’s possible with the owner but non for other viewers. With this style, it will get impossible to maintain the test code when the scenario test case goes up to more than 1000 cases.

The TestCode that followed the Test Scenario Case and has well structured will be looked like as below:

Do you see it? it’s very clear and simple to read. It’s easy to map which test code is represented for which test case in the document. We marked the test number before each test code to make sure the tracking. With the comment, we can understand clearly the purpose of the test code without a look back on the test document.

4. Update UT Coverage

After finish writing the UI Code, and running pass cases, we mark to document and calculate the % coverage of UI Test.

Test Flow Rules:

In case we update the document, we can easily trace the test code base on the test number of the test cases.

For this purpose, our test rule is No change the Test Number of the Test case. Create a New Number instead of changing.

Example of changing test number:

On somedays, we added 1 new test step between №1 and №2: We should do as below:

keep the old test number, add a new one with the rule “Above Test Number + sub number”. In this example: It’s “1.1”

In case add more cases after №3, they will be “3.1, 3.2, 3.3…”

Of course, in our test code, we also keep the old test numbers and add new ones to the test code.