Troubleshoot maven test goal from your IDE

Your Java tests may fail sometimes from different reasons. The most annoying, yet challenging situation happens when they run just fine when you run them one by one, but they are failing when running together:

In this dummy situation inspired by my previous post, the third test is failing only when running it together with the other tests.

This isn’t still a difficult situation because we can easily activate a breakpoint to stop the test execution before the error happens. To debug the test suite, right click and choose Debug instead of Run

When a breakpoint is activated, you get plenty of control over the execution of the program: you can see the stack, explore variables and even evaluate expressions.

There are usually some shortcuts available in your IDE (Mac: option + F8) to open an editor where you can type the java code you need to troubleshoot.

We can see in this situation that our getStuffById method is returning something else (not a CompletableFuture instance) because there is a wrong cache defined for this method. The previous running test used the same cache to store the results for the same key. This situation breaks the rule of having independent running tests and we can fix it by using a cache per method (You shouldn’t use the same bucket to store pears and apples)

Hopefully you automatically run your tests in your pipeline. By default it isn’t this easy to activate the breakpoints when doing a local build (in my situation mvn install but it can be something else):

• If you are using maven-surefire-plugin you can tell maven to wait for an agent to connect when running the tests:

mvn -Dmaven.surefire.debug test

In your IDE edit your running configuration to add this JVM parameter:

Now the tests are waiting for your debugger to connect:

You need to create a new Run Configuration to attach the debugger:

Pressing the lady bug now opens a new console:

Our previous breakpoint works in the same way. The main difference is that we are using mvn test to execute all the tests.

Having this kind of feature in a real world situation is very helpful because usually there are hundreds of tests running in your pipeline and it may be difficult to guess what it’s causing them to fail only when running together. It’s also a good idea to run your tests very often to help you identify problems after a small number of changes in the codebase.