Building Tests Without Bazel

The Bazel plugin now includes experimental support for doing incremental builds of java_test rules without using Bazel.

Removing the overhead of Bazel may decrease the overall compilation time and speed up your build/test/revise cycles. For small, quick-to-run unit tests, this can decrease the time it takes to run the tests from 10s of seconds to under a second.

However, we cannot guarantee that these builds are correct. You may get compilation errors or different test results when you run your tests in this mode. See the How It Works section for more details.

While we will likely never be able to make this work perfectly with every edge case, we’d like to cover as many as possible. If you have issues using fast builds, please file a bug.

Running a Fast Build

Fast builds are run using the “Fast Run” and “Fast Debug” actions. If you have an existing test configuration, you can run it in Fast Build mode by clicking the Fast Run or Fast Debug icons in the navigation bar.

Alternately, you can right-click in a supported test and run it via the “Fast Run” or “Fast Debug” context menu entries.

Once Bazel has completed the build and run your tests, future builds will use javac to compile, without Bazel. If something went wrong with your build and you need to restart it with a fresh build from Bazel, you can click the “Rerun tests with clean build from Bazel” button in the test runner tool window.

You need to do this if the structure of your build changes. When you add a file to the build, for example, you will need to reset the build so that we can get information about the change from Bazel.

If the build failed and the test runner tool window didn’t appear, you can also reset the build from the reset Bazel build notification.

NOTE: In recent versions of IntelliJ (after IJ 2022.2), you will need to add some flags to the VM Options to open the required modules for using javac directly in fast builds. You can add these flags from (Help -> Edit Custom VM Options):
--add-exports=jdk.compiler/com.sun.tools.javac.api=ALL-UNNAMED
--add-exports=jdk.compiler/com.sun.tools.javac.util=ALL-UNNAMED
--add-exports=jdk.compiler/com.sun.tools.javac.file=ALL-UNNAMED

How It Works

We start by using Bazel to build a base jar containing all the class files and resources needed to run your test (a deploy jar, in Bazel parlance). While that build is running, we also run an aspect over the build to gather up information about the Java sources used to compile your project and the annotation processors used for each BUILD rule.

Then we run the test using that deploy jar. We try to set environment variables and system properties the same way Bazel does so your test can’t tell it’s running in a non-standard way.

Once we start the deploy jar build, we track changes to any source files used by your test. The next time you run the test, we run javac over those files, along with the annotation processors indicated in the BUILD files. The deploy jar we built in the initial step is used as the classpath.

Keep in mind, there will always be some builds that we just won’t be able to support. Any source that is post-processed by a genrule, for example, is not likely to ever be supported.

Filing Bugs

Please file bugs in our GitHub issue tracker.

When including details, please be as specific as you can. If the code you’re having issues with is available in a public repository, it’s very helpful to reference a specific file and test target you’re having issues with.