Recently I learned, that it’s possible to script IntelliJ. I picked up on it while Writing an IntelliJ Plugin for my Coverage Tracker project, aka “Undercovered”. So there is the IDE scripting console, which comes out-of-the-box. You just open the Action panel and search for IDE Scripting Console, next a tiny popup menu should show, asking for whether it should be Groovy or Kotlin (beta). Right away you can enter some code and evaluate it by pressing Control + Return....
In a way, this is the last part of my journey creating a Java (Line) Coverage Analyzer. This article concentrates on creating an IntelliJ plugin, that adapts it to show the results collected by the analyzer created in Let’s create a Coverage Analyzer, Part 4. To get started, check out JetBrains’ Developing a Plugin article. With recent IntelliJ versions you need to install the Plugin DevKit first, then create a new Project and select the IDE Plugin Generator....
This is part four of my journey creating a Java (Line) Coverage Analyzer. This time around we’ll test the implementation created in part three and look into details what still goes wrong. One (simplified) example that crashes the current analyzer implementation is this one: public class Demo3 { public static void main(final String[] argv) { final Stuff stuff = new Stuff( !getBoolean()); bla("value: " + stuff.boolValue()); } public static boolean getBoolean() { return true; } private static void bla(final String greeting) { System....
This is part three of my journey creating a Java (Line) Coverage Analyzer. This time around we’ll look into improving the very naive implementation created in part two. That one ended in a VerifyError and the message Expecting a stackmap frame at branch target 41 So what is this branch target, and the stackmap frame that it’s suddenly missing? To have an easier time inspecting the Byte Code, let’s first create a little CLI version of our instrumentation code....
This is part two of my journey creating a Java (Line) Coverage Analyzer. Here we’ll actually implement the Byte Code Instrumentation, as pointed out in the first part. Since processing the Byte Code itself, i.e. reading the classes, finding the methods, processing line number information, is in itself a huge task, let’s rely on the ASM library for that. After all JaCoCo and Cobertura also rely on that, so this seems to be a valid choice 😂...
Have you ever wondered what happens when you click on “Run with Coverage” in IntelliJ? Obviously it’s running the tests, but how is it collecting the coverage information? Let’s create a simple Line Coverage Analyzer in and for Java 🥳 First of all, let’s write a simple example program (see GitHub) package de.brokenpipe.dojo.undercovered.demo; public class Demo { public static void main(final String[] argv) { final String greeting = "Hello World"; bla(greeting); bla("to the blarg"); } private static void bla(final String greeting) { System....
Today (err, recently) I learned … that JUnit’s extension API allows for parameter resolvers. These kick in every time you use arguments on a test method, lifecycle method or class constructor. For me, so far, none of these methods ever took an argument. But turns out, it’s possible … and even useful. They have a primitive example here where they allow a test method to take a random number like so:...
Today, I discovered a powerful feature in JUnit: the Assumptions API. This API allows you to define assumptions for your tests. If an assumption isn’t met, the test execution is aborted rather than marked as failed. This distinction is crucial in scenarios like conditional test execution in CI pipelines. When a test is skipped due to an unmet assumption, it appears as “skipped” in the test reports, not as “passed” or “failed....