Accelerate
Troubleshoot
Observe
Test Distribution is an approach that accelerates test execution and complements build caching while addressing many of the limitations of single-machine parallelism and CI fanout. It does this by extending test parallelism which farms out test execution to remote executors. Along with Build Cache, it is one of the major build and test acceleration features available in Develocity.
We caught up with Cédric Champeau, consulting member of the technical staff at Oracle, a former engineer on the Gradle Build Tool core team and a Groovy committer, to ask him about his experience with Test Distribution (TD) while working at Gradle on the Gradle Build Tool open source project.
Overall, what impact has TD had on your developer experience?
Local test distribution is so awesome. I don’t recall any feature which had such an impact on my productivity. My test suites finished in 5 minutes instead of 54. That’s 10x! The 10x developer is finally here! As an application developer waiting for test suites to complete can crush my creative flow. Fast feedback cycles are the key to developer productivity and satisfaction.
How would you characterize your usage of TD?
The Gradle Build Tool team has Develocity built into their projects. I personally used Build Scan™ when things went wrong, like when a build takes way longer than usual, when there is a CI failure, or when we experienced non-verification failures — which are failures with no good feedback for developers. But I used Develocity Build Cache and TD regularly because I saw the benefits everyday. My preferred process is to modify some code locally then run all the tests suites before sending everything to CI.
What was life like before and after TD?
Before, I ran local builds that would take about 45 minutes to complete. I would run a pull request (PR) build on CI against the entire test suite including all unit and integration tests across my multi-project build and cross my fingers. It’s mentally draining when something goes wrong and it doesn’t pass a test suite. In those cases, as I saw tests fail in a PR build, I would have to wait 45 minutes to get access to a Build Scan™ in order to troubleshoot. After TD was enabled I ran the PR build locally and got feedback in 5 minutes. I run PR builds locally because I don’t want to go through CI until I have full confidence it will pass CI. Running a PR build with TD locally before running that PR in CI is the new workflow that makes me significantly more productive.
For those considering deploying TD, do you have any parting thoughts or advice?
Yes, it’s important to acknowledge that test time is often the primary driver of your overall build times and can represent up to 90% of your wait time. There are many factors that contribute to this including the growing number of integration and functional tests to cover a wide range of inputs, dependencies on expensive external services, and unnecessarily running tests sequentially. TD is one of the best techniques to address the avoidable pain associated with long build and test feedback cycles. Minimizing the length of feedback cycles means I can spend a greater proportion of my time focused on coding and my team can ship quality code faster. That makes me a happier developer.