Building Tests Without Bazel
The Bazel plugin now includes experimental support for doing incremental builds
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.
This code is somewhat experimental, but it seems to be working well for many people. We’d like to make it better, so if you find issues, 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 link in the Bazel console.
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.
On subsequent builds, we query the version control system to see what files have changed since we built the deploy jar. 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.
At the moment, that’s basically the extent of it. We expect there to be a significant number of builds that aren’t covered by these simple heuristics and we’ll work to address those issues where we can. If you have a build that doesn’t work and you think it should, please file a bug.
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.
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.