Running Unit Tests Only in Affected Modules with Affected Module Detector

This article was translated from Japanese by Claude Code.

I’ll introduce the content in the title. I’m only writing about what can be understood from reading the Affected Module Detector README and implementation code. I’m assuming a case where you want to run UnitTests in an Android project. This information is from the time of writing, so please refer to the project README for the latest information.

What is Affected Module Detector?

#

It’s a Gradle Plugin developed by Dropbox.

github.com

It retrieves the latest commit and detects modules affected by the commit (affected modules). Specifically, it can detect affected modules and the dependency graph that depends on those modules.

What’s the benefit?

#

If you can detect modules affected by the last commit (or modules that depend on those modules), it becomes possible to run only tests that may have been affected by the last commit. If you can achieve this, for example, you can shorten CI test execution time.

Requirements

#

As a requirement for using Affected Module Detector, the project must be under Git version control.

Available Options

#

Options are provided to specify which scope of impact to detect when running Affected Module Detector.

• Changed Projects: These are projects which had files changed within them – enabled with -Paffected_module_detector.changedProjects)

  • → Projects that were changed

• Dependent Projects: These are projects which are dependent on projects which had changes within them – enabled with -Paffected_module_detector.dependentProjects)

  • → Projects that depend on changed projects

• All Affected Projects: This is the union of Changed Projects and Dependent Projects (this is the default configuration)

  • → Changed projects + projects that depend on changed projects

The project README describes examples like running Changed Projects tests triggered by a PR, and running All Affected Projects tests triggered by a PR merge.

Trying It Out

#

Setup

#

Set up as described in the README.

First, add the following to the root build.gradle:

buildscript {
  repositories {
    maven()
  }
  dependencies {
    classpath "com.dropbox.affectedmoduledetector:affectedmoduledetector:<LATEST_VERSION>"
  }
}

apply plugin: "com.dropbox.affectedmoduledetector"

affectedModuleDetector {
    baseDir = "${project.rootDir}"
//    logFilename = "output.log"
//    logFolder = "${project.rootDir}/output"
    excludedModules = [
        "sample-util"
    ]
}

Configure settings within affectedModuleDetector { }.

To verify tests are running correctly locally, specify logFilename and logFolder. It will log which modules were detected when commands are executed.

In excludedModules, specify modules you want to exclude from detection. I expect this will shorten detection processing time if set appropriately. (I haven’t actually measured this)

Then add the following to each module’s build.gradle that has tests:

affectedTestConfiguration {
  jvmTestTask = "testDebugUnitTest"
}

I’ve extracted just this description into a separate build.gradle and applied it using apply.

Running the Command

#

Run the following command with detector enable to enable the detector and run tests:

./gradlew runAffectedUnitTests -Paffected_module_detector.enable

After setup, when I ran the above command locally, all tests ran the first time, and running it again immediately showed them being skipped.

Impressions

#

I haven’t done precise measurements, but since tests that aren’t affected can be skipped using Affected Module Detector, it’s contributed somewhat to shortening CI test time. I find that useful.

At the time of writing, there was no description about jvmTestTask configuration in the README, so it took time to find. (I was lucky - I went to read the Plugin code, thought “maybe this?”, tried it, and it worked.)

I haven’t yet confirmed whether integration with test coverage tools works well, so if there’s anyone kind with knowledge about this, I’d appreciate if you could let me know. This is on my TODO list going forward.

If there are any mistakes in this article, I’d appreciate your feedback 🙏

It’s rough, but that’s all~~ ｽﾞｻｰｯε=ε=ε=c⌒っﾟДﾟ)っ