Time is precious. Waste it wisely.

Time is precious, and there’s no doubt here. We all like to wait as little time as possible for something. We all want to control our time. And that’s the purpose of this article: to promote knowledge sharing and encourage you to share your practices with us.

Here at Mercadona, we have CI/CD in our projects. We run our pipelines when we open a PR and merge to master when we deploy a new version…

Let’s focus on the last point: reducing our pipeline time means a lower waiting time for deploying a new version.

The less waiting time, the more we will be willing to deploy frequently. And deploy more frequently means our deployments would be smaller and safer (as we talk in this article about continuous deployment). It sounds like a huge benefit!

If you work with some automated tasks, I’m pretty sure you’re tired of waiting for them to finish, and so we are. That’s why, from time to time, we rethink our processes and challenge ourselves to reduce our pipeline time, no matter how small change gets implemented.
Even if you save 10 seconds, it’s worth it. The more you run the pipeline, the more time gets saved.

And here’s where our story begins: trying to imitate our iOS mates. They saved a massive amount of time running their tests on different devices simultaneously.

Thanks to our mate Voro we started to research if there were something similar in android, and we started from here.

What did we have?

• Some scripts to initialize our backend API in our local environment.
• Fastlane and its plugin to create the AVD (Android Virtual Device) where we run the instrumentation tests.
• A list of one AVD configuration:

• Our tests with Barista.
• A stage in our Jenkins pipeline which lasted around 12 minutes.

What did we want?

Thanks to our tests being independent, we wanted to split them to run in parallel to reduce our pipeline time.

What did we do?

Obviously, searching on the Internet. And, of course, with that feeling of having no idea of where we were going. We started to work together, Edgar, Voro, and me, during a week or so, and taking some snippets we were finding and mixing them like a tailor, we came something that seemed a good solution.

Now we were able to run tests in parallel, but what could be the correct number of AVDs? We started with two, and the time was reduced from 12 mins to 10 and a half. We made another attempt with three AVDs and the time decreased to 8 and a half. Just out of curiosity, we tried it with four, but surprisingly the time was more or less the same as with three, so we considered three the right number of AVDs.

We reduced the time of the tests by almost 4 minutes (20–30% less than before)!

Message from our mate Edgar to share our successes with the rest of the Engineering team

📽 And here’s the video, just in case you want to see it.

Parallel Android e2e testing

What do we have now?

First of all, we have to add more AVDs to our list. As we didn’t want to change our configuration, we just copied and pasted what there was and changed the name and the port:

Next, we created a script to start all the emulators from the command line:

We create another script for launching the tests. As you can see in the gradle command ./gradlew :app:connectedE2eDebugAndroidTest ,we have a buildType debug and a productFlavor e2e (you can replace them with yours):

After that, we joined our scripts to initialize our backend API in our local environment with the new ones:

Finally, we changed our lane in our fastfile, and it looks pretty well!

Next steps and conclusions

We want to understand the criteria for sending a test to a specific device. If you have seen the video, in the end, there’s only one device running tests; meanwhile, the other two are idling.

Surely we can improve our scripts to reduce the number of lines. For instance, we could read our AVD list file instead of having them in the emulators variable.

And also, we would like to try other actions to reduce our total pipeline time, such as splitting the code into different modules to reduce the building time.

Every second counts! Have you ever stopped to rethink and analyse every stage in your pipeline? How do you save time in your automated tasks?

I’ll be glad to read your tricks in the comments, or even better, and maybe you want to join us to face these problems? We are hiring!