Swiggy • Anik Raj C • Jan 24, 2023

Gradle Incremental Test Runner

M2 Related OWASP risk: Inadequate Supply Chain Security Learn more →

Article Summary

Swiggy's Android team was stuck in a painful cycle: rebasing PRs, waiting hours for full test suites to run, then doing it all over again. One frustrated engineer decided to fix it over a weekend.

Anik Raj C from Swiggy's Android team built a Gradle Incremental Test Runner that identifies which tests actually need to run based on code changes. Instead of running thousands of tests on every PR, the tool uses git diff and intelligent file searching to run only relevant tests.

Key Takeaways

Reduced average test run time from hours to just 6 minutes
Uses git diff and grep to map changed files to related tests
Runs locally on developer machines, eliminating CI wait times
Cuts CI compute costs dramatically by running subset of tests
Built initial prototype using bash scripts over one weekend

Critical Insight

By running only relevant tests instead of the entire suite, Swiggy reduced test time to 6 minutes and slashed CI costs while improving developer productivity.

The article reveals the specific bash commands and Gradle flags that made this possible, plus the team's plans for making it even more accurate.

About This Article

Problem

Swiggy's codebase grew to the point where thousands of tests ran on every PR. Developers got stuck in a frustrating loop of rebasing and waiting for the full test suite to finish before they could merge their code.

Solution

Anik Raj C built a Gradle Incremental Test Runner that uses git diff to find which source files changed. The tool then searches test directories with grep and xargs to locate the related test files and runs only those tests using Gradle's --test filter flag.

Impact

Test execution time dropped to 6 minutes on local machines. CI compute costs fell significantly because the tool only ran relevant tests instead of the entire suite. Developers could now validate their changes in minutes instead of hours.