Introduction

To run a Gradle build without tests, pass -x test on the command line:

gradle build -x test

The -x flag excludes a named task from the build execution graph. Since test is the standard task that runs unit tests, excluding it skips test compilation and execution while still compiling your main source code, processing resources, and producing the output artifact.

How Gradle Task Exclusion Works

Gradle builds are organized as a directed acyclic graph (DAG) of tasks. When you run gradle build, Gradle resolves all tasks that build depends on, including compileJava, processResources, classes, jar, test, and check. The -x flag removes a task and all tasks that exist solely because of that dependency.

# See the full task graph without executing
gradle build --dry-run

When you exclude test, Gradle also skips check (which depends on test) and any custom tasks that depend exclusively on test. Tasks that test depends on, like compileTestJava, may still run if other tasks need them, but in practice they are usually pruned.

Excluding Multiple Test Tasks

Projects with integration tests, functional tests, or other custom test tasks need multiple exclusions:

1# Skip unit tests and integration tests
2gradle build -x test -x integrationTest
3
4# Skip all tasks that match a pattern (Gradle 6.5+)
5gradle build -x test -x functionalTest -x contractTest

For multi-module projects, the -x flag applies globally. To skip tests in a specific submodule only:

gradle :api:build -x :api:test

Using the Gradle Wrapper

Most projects use the Gradle wrapper (gradlew) instead of a system-installed Gradle. The syntax is identical:

./gradlew build -x test

On Windows:

gradlew.bat build -x test

Always prefer ./gradlew over gradle to ensure everyone on the team uses the same Gradle version.

Skipping Tests in build.gradle

Disabling the Test Task Permanently

If tests should never run as part of the default build (rare, but sometimes appropriate for documentation-only modules), disable the task in build.gradle:

test {
    enabled = false
}

In Kotlin DSL (build.gradle.kts):

tasks.test {
    enabled = false
}

Conditional Skipping With a Project Property

A more flexible approach is to skip tests only when a property is passed:

1if (project.hasProperty('skipTests')) {
2    test {
3        enabled = false
4    }
5}

Then invoke the build with:

./gradlew build -PskipTests

This keeps tests enabled by default but gives developers a quick escape hatch during iterative development.

Conditional Skipping With a System Property

System properties work similarly and integrate well with CI environment variables:

1test {
2    if (System.getProperty('skipTests') != null) {
3        enabled = false
4    }
5}

./gradlew build -DskipTests

Skipping Tests in CI/CD Pipelines

In CI environments, you typically want tests to run on every build. But there are valid reasons to skip them in specific pipeline stages, such as a deployment step that only needs the artifact:

1# GitHub Actions example
2jobs:
3  deploy:
4    steps:
5      - name: Build artifact without tests
6        run: ./gradlew build -x test
7
8      - name: Deploy
9        run: ./deploy.sh build/libs/*.jar

For branch-based skipping in the build script itself:

1if (System.getenv('CI_SKIP_TESTS') == 'true') {
2    tasks.withType(Test) {
3        enabled = false
4    }
5}

The tasks.withType(Test) selector disables all test tasks regardless of their name, which is cleaner than listing each one individually.

Comparison of Methods

What Gets Skipped vs. What Still Runs

Understanding exactly what -x test skips is important:

If you only need the JAR and do not need the check lifecycle at all, gradle assemble is an alternative that never includes tests:

./gradlew assemble

This produces the same artifact as build without running any verification tasks.

The --no-build-cache and --rerun-tasks Interaction

When you skip tests during development and later run a full build, Gradle's build cache may report tests as "UP-TO-DATE" even though they never ran. This happens because the test inputs (compiled test classes) have not changed. To force tests to execute:

./gradlew test --rerun-tasks

Or clear the build cache entirely:

./gradlew clean test

Common Pitfalls

Skipping tests during development and forgetting to run them before pushing is the most common issue. The build passes locally because tests were excluded, but CI fails because it runs the full build. Make running ./gradlew build (with tests) a habit before committing.

Using test { enabled = false } in build.gradle and forgetting about it means tests silently stop running for everyone, including CI. This configuration should almost never be checked into a shared repository without a clear comment explaining why.

Excluding test but not integrationTest (or other custom test tasks) gives a false sense of speed when the integration tests are the slow part. List all test-type tasks with ./gradlew tasks --group verification to know what you need to exclude.

Running gradle assemble when you actually need build skips not just tests but also other verification tasks like checkstyle, pmd, or spotbugs. Make sure you are aware of what check includes before bypassing it entirely.

In multi-module builds, -x test applies globally. If you only want to skip tests for one module, use the fully qualified task name: -x :module-name:test.

Summary

• Use ./gradlew build -x test to exclude tests from a single build invocation.
• Use ./gradlew assemble when you only need the artifact and no verification at all.
• Add -PskipTests support in build.gradle for a team-friendly opt-in flag.
• Use tasks.withType(Test) { enabled = false } to disable all test tasks programmatically.
• Always run the full build with tests before pushing to avoid CI surprises.
• Prefer the Gradle wrapper (./gradlew) over the system gradle binary for reproducible builds.