Creating an Annotation Processor means that you will likely also want to add tests, but this can be tricky since the runtime is the compilation process itself, meaning that you will have to invoke a compilation step during test execution. In this post I’d like to outline what you can do to ensure proper test coverage.

Annotation Processing

In Java, Annotations allow compile-time metaprogramming, meaning that it allows creating code based on other source code. I use this in Java - Lenses to create auxiliary classes for annotated records. These contain various instances and functions which need the type information of the annotated records, meaning that there is no way to this directly in the source code itself.

Many applications have APIs consuming and returning JSON. If you do not cover the expected inputs and output of the API you risk introducing unintentional changes. Luckily it is not hard to create these valuable test cases. If you have types that are used both as symmetrical inputs and outputs this test pattern will provide full coverage and give you utility methods for other tests as well.

For this example I’ll be using a type Task having just a name and a description field, both Strings:

For my full-stack projects I like to use Server-Side rendering with Javalin, j2html and htmx. Together, these libraries allow you to write interactive full-stack web applications in vanilla java. In this post I’d like to explain how the j2html library fits in this setup, go over a few benefits, and link a converter that I wrote to make building the user interface easier.

Server Side Rendering

While the last decade was dominated by client-side frameworks, many applications could perhaps have saved a lot of development time by using server-side rendering. This means that the resulting html is built on the server, including its data, styling and behaviour.

Immutability

Using immutable types has a number of benefits. Since it eliminates mutation, it makes code easier to reason about. Also, it eliminates concurrent modification problems, thereby unlocking a lot of performance improvement opportunities. Java originally was fully Object-Oriented but it adapted to other paradigms. The language itself still lacks some features that makes it convenient to work with immutable data. In this post I’d like to show what can currently be done in vanilla Java and show a powerful concept to transform immutable data.

Writing tests on asynchronous code can be a challenge. Given an asynchronous process to test, we may try to use custom code to wait for the process to finish or reach a certain state. This may cause us to end up with tests that are flaky, slow, or hard to understand. It is not uncommon for legacy projects to have these setups, and perhaps they can be improved a little.

When you have a Java Enum with a field, a requirement can be that the field value needs to be unique. Using a utility method it can be easy to create a test for this. Given an Enum class with a field (using some Lombok):

@Getter
@RequiredArgsConstructor
@Accessors(fluent = true)
public enum Sides {  
    LEFT("left"),  
    RIGHT("right");  
  
    final String label;
}

You can enforce uniqueness using a unit test:

  
import io.vavr.collection.HashMap;  
import io.vavr.collection.Vector;  
import org.junit.jupiter.api.Test;  
  
import java.util.function.Function;  
  
import static org.junit.jupiter.api.Assertions.assertEquals;  
  
class SidesTest {  
    @Test  
    void unique() {  
        assertUnique(Sides.values(), Sides::label);  
    }  
  
    private static <T> void assertUnique(T[] values, Function<T, String> fieldValue) {  
        assertEquals(  
            HashMap.empty(),  
            Vector.of(values)  
                .groupBy(fieldValue)  
                .filter(it -> it._2().size() > 1));  
    }  
}

The test will automatically validate that all fields have distinct values, even if the Enum expands or changes in the future. Failures will report the enum values that have the same property. If we misconfigure the enum above ( RIGHT("left")) we see which value occurred multiple times, and in which Enum values:

Writing code assuming everything will follow the happy path may not result in the best software quality or user experience. Sometimes we choose to ignore unhappy paths, or lack awareness of the existence of unhappy paths. Both of these scenarios can lead to runtime bugs and problems for customers which may be good to prevent.

Many strategies and coding styles exist in different languages to give the developer tools to address this issue. In this post I’d like to explore some of them and illustrate my preferences.