Bazel Test, JUnit5 and Micronaut -Growing the relationship

In my previous post, Bazel and Micronaut – An unlikely beautiful match, we explored how to get Bazel, Kotlin and all the Micronaut annotation processors working happily together, and when it was complete, it was a GREAT match. But, there is a glaring omission in the post. There were no tests. Both Bazel and Micronaut are very proud of their testing heritage, and rightly so. Both mention testing in their main descriptions. To really do this new match any sort of justice, we have to have testing. For those of you that have seen one of our presentations or read the insights, you know Dilbert has to have something to say about me putting out the first post with "production code" and no tests.

The Challenges

The biggest challenge I faced was figuring out how to ensure the proper Micronaut annotation processors ran against the test class. The second biggest challenge was getting this to work with JUnit5 which is not a standard Bazel example. Luckily, on this front, the JUnit team put together a nice example to base things on. Of course it was for Java, and didn’t have anything to do with Micronaut, but it gave me some hints. Micronaut also provided an example in Gradle and Maven which also gave some more hints.

The Solution

After some experimenting, I figured out the kt_jvm_test rule was the best option for our code base. The real challenge was figuring out the correct arguments for the rule.

In the code snippet above, the main_class is set to the ConsoleLauncher so Bazel knows to run the test harness, the args tells the test framework what packages/sub-packages to scan for *Test.kt files and finally we point the rule to the source files to compile for testing.

In Micronaut, we might want to specify a specific settings file or logging. In our case we didn’t , but if you did, we would add it like the snippet below.

To compile our tests, and ensure all the Micronaut annotation processors are run (kapt in Kotlin) we need to bring in some dependencies.

If you read the previous post, you are familiar with what :micronaut_lib is doing. This is where the magic happens that makes Micronaut so awesome. If you skipped ahead, go back and read the previous post, you know who you are ;). The inclusion of the two micronaut_test dependencies enable the Micronaut testing magic, and also point out how dependencies can be hidden by Maven and Gradle. On a side note here, this is one of the primary reasons to use Bazel over either of these more popular JVM build tools.

The bottom four dependencies are how we get the Jupiter JUnit 5 framework dependencies in the test compile. Once we have it compiling, we still need to define our runtime dependencies.

The test code itself is just a simple contract test for the services.

To run the tests, you can call the specific test rule with bazel test //:micronaut_tests or you can use the "run all the tests" with bazel test //... which in our simple case does the exact same thing. One of the nice things about Bazel is its caching and avoidance. If something didn’t change, don’t redo the work. Since I have run my tests several times, I get the following results:

To find your results, you look in the bazel-testlogs directory under the name you added for the rule. In our case that is micronaut_tests. The file is test.xml. Our test summary looks like this (pulled from the test.xml file)

You can find all the code for this and the first post in our Github repository here https://github.com/SUMGlobal/bazel-micronaut-example. We would love to hear what you think of the post. Leave a comment below.