In one of our core services, the execution of a single unit test took approximately 30 seconds, while a single integration test ranged between 65 and 70 seconds. Running the entire test suite took circa 6 minutes.
Currently, in the Android world, the topic of modularization is very popular. Many bloggers describe their experiences with it and analyze what Google recommends. Our team started the modularization process before it was hot. I will describe our reasons, decisions, problems and give you some advice. We will see if modularization makes sense and what it brings to the table. I will also post some statistics showing what it looked like before and after the modularization process.
The story begins two years ago during an excellent TDD training given by Szczepan Faber and Tomek Kaczanowski for a bunch of Allegro developers. Surprisingly, it was a trigger to revolutionize our builds at Allegro.
Typically, applications we develop gain more and more features in each sprint. After a certain time it’s hard to say how a particular functionality should work. No one remembers all the corner cases without looking into the source code. So we write high level acceptance tests that describe expected behavior. Using some example scenarios that the end user could trigger, tests check that the outcome is correct. After the user story is implemented, the test joins a regression suite that will protect the application from bugs introduced in future stories.
In the good old days of Maven releasing projects was straightforward. Everyone knew and used maven-release-plugin, a plugin that behind simple facade did huge amounts of work. In Gradle times things started to get complicated. In exchange for greater flexibility we gave up good old, maybe a bit rusty tools that were part of our developer kits for years. Now we try to find new ones. Most of teams in Allegro have decided to migrate their projects from Maven to Gradle and we, too, are searching for perfect tools to do our job (and builds).
