Maven Failsafe Plugin environmentVariables Not Working (org.postgresql.Driver claims to not accept jdbcUrl)

A few months ago I had written about how one can setup a PostgreSQL database in a docker container during the Maven testing phase (part 1 and part 2). Today, I wanted to iterate on this topic using Testcontainers. Unfortunately, before I could get to that I ran into issues with the original project. For some reason I was now getting the following error:

Caused by: java.lang.RuntimeException: Driver org.postgresql.Driver claims to not accept jdbcUrl, jdbc:postgresql://localhost:${it-database.port}/docker_db_testing_tests

Maven did not replace the variable it-database in the integration test application.properties file. The question is: "why now"? It has worked before. Now, one thing that I changed is that this time I was using Linux instead of Windows. Either way, the fix was simple, although not obvious. It seems to be an issue with the Maven Failsafe plugin.

Not working:

<configuration>
    <environmentVariables>
        <it-database.port>${it-database.port}</it-database.port>
    </environmentVariables>
</configuration>

Working:

<configuration>
    <systemPropertyVariables>
        <it-database.port>${it-database.port}</it-database.port>
    </systemPropertyVariables>
</configuration>

Here is the link to the commit.

Mockito “when” vs. “verify”

Recently, during a code review at work there was a discussion about whether Mockito’s verify is necessary when when (or given, which is a synonym) is parameterized. The quick answer is "no".

Imagine this contrived example. I have two classes, Calculator and ComplexOperationService, where the latter requires the former. The goal is to write a unit test for ComplexOperationService and mock all usages of Calculator.

Here are the two classes.

public class Calculator {

    public int sum(final int a, final int b) {
        return a + b;
    }
}

@RequiredArgsConstructor
public class ComplexOperationService {
    
    private final Calculator calculator;

    public void doComplexOperation(final int a, final int b) {
        System.out.println(calculator.sum(a, b));
    }
}
Read More »

Integration Testing with Docker Maven Plugin, PostgreSQL, Flyway (Update)

Recently I have written about how one can create a PostgreSQL Docker image with the Docker Maven Plugin to run integration tests that require a database. While this worked all nice and well during development, the concept has one flaw: the plugin will push the database Docker image to a Docker registry during the deploy phase. I do not want this temporary image to end up there. This is the behavior of the Docker Maven Plugin and I have not found a way to work around this. By “work around this” I mean somehow configure the plugin to ignore this custom PSQL image during the “deploy” phase. Unfortunately, there is only a global <filter> that applies to all the phases of the plugin.

There is a proper solution however, at least for what I was using the database.

Read More »

Integration Testing With Docker Maven Plugin, PostgreSQL, Flyway

Some things in software development require more than mocks and unit testing. If your application uses a database it makes sense to also hit that database in automated testing to ensure custom SQL queries work correctly, Hibernate relations are set up properly and also that database migrations are successful.

This blog post was written with a focus on the latter. I will be using Spring Boot talking to a PostgreSQL database. The database structure is managed via Flyway and, basically customary for Java applications, Maven serves as the build and dependency management tool. Docker will also play a role because we’ll be creating and running a PostgreSQL docker image for testing. From Maven. Every time the test is executed. And to spice things up, we’ll also create a custom database and user in that dockerized PSQL image.

I have created a working sample on Github and you can follow every single step by taking a look at the commit history. There you can see individual changes, starting from an empty Spring Boot application with no database to the final solution with Spring Data JPA and Flyway.

In the following sections and snippets, I will highlight the important parts of each step.

Read More »

Unwanted JUnit 4 Dependency with Kotlin and JUnit 5

I ran across this issue only by accident because I was investigating a completely different problem. I wrote a quick test to debug my issue and was wondering why custom serializers and deserializers are not registered with the Jackson ObjectMapper. I had a nice init() function that was annotated with @Before. So, what the hell?

Let’s back up a bit for some context.

  • Kotlin Project
  • Runs on Java 12
  • JUnit 5 as test engine
  • AssertK for assertions (just for the sake of completeness)

I’m used to JUnit 4, so in my test I used @Before to annotate a setup method. It was one of the many options IntelliJ presented to me.

@Before
fun init() {
    val module = SimpleModule()
    module.addDeserializer(Instant::class.java, InstantDeserializer())
    module.addSerializer(Instant::class.java, InstantSerializer())
    mapper.registerModule(module)
}

The method wasn’t called, however. But it’s annotated! Well, it’s the wrong annotation if you’re using JUnit 5. The correct one is @BeforeEach. This one and @BeforeClass (new name @BeforeAll) have been changed from version 4 to 5 to make their meaning more obvious.

But that’s besides the point. The question is: where does this @Before come from then?

A look at the dependency tree quickly reveals the culprit.

It’s the official JetBrains Kotlin JUnit test artifact. Although it doesn’t hurt me to have it in my project, it certainly caused some confusion and I’d like to avoid that in the future. Hence, I excluded the old version of JUnit in my POM file for this dependency.

<dependency>
    <groupId>org.jetbrains.kotlin</groupId>
    <artifactId>kotlin-test-junit</artifactId>
    <version>${kotlin.version}</version>
    <scope>test</scope>
    <exclusions>
        <exclusion>
            <groupId>junit</groupId>
            <artifactId>junit</artifactId>
        </exclusion>
    </exclusions>
</dependency>

Problem solved.

A Java “DSL“ for Simple Unit Test Data Creation

I’m a person that usually writes tests before the implementation. In the context of my backup application project this has turned out to really slow me down. But it’s not just a problem of my personal projects. It also affects my professional work. 

Here’s the issue: for some tests you need test data and generating that test data can be a tedious task, depending on the complexity. This has caused me to procrastinate on my backup app. So, one evening, after having thought about this during a workout, I grabbed my laptop, sat down in my comfy bed and wrote a “DSL” that makes creating the data much simpler. Not only is it easier to create the data now, allowing me to continue at a faster pace, it’s also much more readable and the test setup doesn’t clutter the test case anymore. This is a very important aspect of a test. What good does it to have one if, after some time, you have to update it and don’t understand what it does anymore?

Read More »

Using Groovy Spock in a Maven Java Project

Groovy Spock is a testing framework that can be used as an alternative to the venerable JUnit. In Java projects it’s probably very common (I don’t have any data, just an assumption based on how I think) to also use a Java based testing framework. The most widely known is JUnit, although not the only one of its kind (e.g. see this article on DZone). However, Java’s syntax can sometimes be rather cumbersome and verbose, and this is where a dynamic language like Groovy can help. It is often used to create nice and interesting DSLs, e.g. as the basis of the Gradle project or, as in the case of Spock, for testing.

Here’s how to integrate the Groovy Spock testing framework in a Maven based Java project.

One thing up front: I’m no fan of Groovy. I’ve worked with Grails projects for several years and using Groovy has more than once proven to be a problem. Especially in very large applications. However, I do see the benefits it can provide in certain situations and I have come to like the more expressive, although sometimes odd to read, Spock DSL in tests.

Read More »