AutomationTestSupervisor — what does it have to offer?

Tool can be divided into four main modules where each of them has it’s own config manifest file. Modules are integrated which each other and forming linear pipeline with set of steps. By modifying manifest of each module you can adjust behaviour of each step.

Path Module

This module is responsible for storing all machine related paths on which ATS will build it’s files. Depending on your setup ATS can be either another project stored on each PC that you use for testing, submodule of your Android project or even part of it.

If you have already set ANDROID_HOME or ANDROID_SDK_HOME environment variables then all you need is to set path to your folder with .apk files. If you want them to be built by ATS then you need to specify path to your Android project because access to gradle binary file is necessary to trigger build commands of your application.

Lauch Plan Module

This module can be compared to global config.

In this manifest you can decide how many ADB commands can be launched at the same time and specify time interval between them. Weaker machines have problem with handling many ADB commands. Too many calls to ADB at the same time may result in error. Additionally it is possible to pick if AVD should be reused or recreated according to schemas from AVD module. You can decide if you want to reuse existing .apk or build new one. There is possibility to modify how machine should wait for AVD launch - all at once (not recommended) or in sequence. You can also pick launch timeout value or specify list of ignored devices. There is possibility to use screen recording feature. Screenshot feature is not supported, if you want to learn more about it visit our repo.

AVD Module

This module is responsible for AVD creation. It stores AVD models in JSON schemas. You can create as much schemas as you want and bind them to AVD groups.

To create schema you need to fill data according to Google’s documentation. There is possibility to specify absolute path to emulator image if you want to load some previously prepared device state. You can also overwrite config.ini. It is recommended to use config.ini as you are unable to set every parameter of AVD from terminal. From created schemas you can combine sets where you can pick how many instances of each AVD should be launched. ATS will adjust names and pick open ports for you. You can also modify which ports you would like to use.

Usage of this module is optional. ATS is capable of running tests on currently launched devices. The only restriction is that if you decide to use AVD module then real devices will be ignored and all other currently launched AVD will be killed. ADB cannot handle many sessions. Did you try building Android .apk while tests are running? You can’t. The same way ATS needs to take over control of ADB.

Test Module

This module grants you possibility to create sets of test packages but beforehand you need to list up all test packages (the same way you lists activity in your Android app manifest).

It might look like a lot of work but it’s actually not. Remember that you are doing it only once. Fields “test_classes” and “test_cases” are unused. We had in plan to run every test case separately and clear app state every test and those fields were for this purpose. But this feature was provided by Google in form of adb orchiestrator few months ago so there is no need to implement it anymore.

In the end all you need to do is create alias — shortcut of package name and set package name to it. Example of how it could look like can be found here.

Additionally you can specify more test parameters like shards, gradle parameters, gradle task for building application .apk and test .apk. You can hardcode .apk name but it won’t be too practical if it contains versioning. Therefore you can insert part of your .apk name. ATS will search for .apk files containing this name part in “apk_dir” of Path Module. If there is no .apk found (or there is .apk but there is no test .apk built for it) ATS can build one if you have set “project_dir” in Path Module and set “build_apk” option in Launch Module. If there will be more than one .apk matching name part ATS will search for .apk with highest version code.

Launching ATS

If you have properly set your machine then you need one line of code to launch ATS. You have four optional parameters:

aset (AVD set)

tset (Test set)

lplan (Launch plan)

pset (Path set)

Example how command can look like:

python3 Launcher.py -aset 3AVD-23 -tset function_all_shard

I am specifying which tests should be ran and which AVD should be launched. I don’t need to specify other parameters because I am using pre-configured defaults. Order is also not important.

There is much more you can expect

There are much more good points that we cannot fit in this very first post about ATS so we will list them up.

Few additional features of ATS: