I’m currently in the early stages of rewriting a large and complex Java code base to Kotlin. Some parts of this codebase are really ugly and unnecessarily complicated and convoluted. Yesterday I crossed the path of a nasty use of a switch statement in an operation on a Java Stream. Unfortunately I can’t share the real code, but imagine something like this:

int value1;
int value2;

for (...) {
    switch (enum) {
        case Enum.FOO:
            if (something) {
                if (somethingElse) {
                    value1 = someConvolutedStreamOperations();
                    value2 = someOtherConvolutedStreamOperations();
                    // imagine 30 more lines here
                } else {
                    value2 = 0;
                }

                break;
            }

        case Enum.BAR:
        default:
            value1 = 1;
            value2 = 2;

            break;
    }
}

This was part of a Java class with over 1,000 lines of code. Streams with many operations everywhere and sometimes very deep nesting thanks to old-style Java code. The original case for Enum.FOO stretches over almost the whole display space, so it’s not easy to spot any potential pitfalls. After I ran IntelliJ’s Kotlin migration tool and cleaned up all errors, it was time to run the unit tests and four out of 24 failed.

As you can imagine it’s not straight forward to find problems in such a large and complex class but I came across a notice of an unused value assignment. Why it was there was also not clear immediately, so I compared the original Java file with the Kotlin version.

Since Kotlin has no switch IntelliJ converted it to when. Unlike its Java counterpart when can handle null and is exhaustive with enums. There is also no break keyword and that’s exactly the problem here.

Look at the Java code and think about what happens on Enum.FOO if something is true but somethingElse isn’t. The break keyword is not triggered and the switch statement goes on to the default block. As a result value1 and value2 are assigned their values.

IntelliJ’s migration tool is quite good, but it didn’t catch that and the generated when statement was wrong. That’s also the reason for the unused assignment notice. I assume the migration tool was confused by the scope of break since both switch and for can use it. Also there is no real match in Kotlin for such a structure. You have to assign the values of both variables for every branch inside the when statement. After fixing that all tests ran successfully.

It’s a really good example of how not to use switch statements, especially with nested control structures in a case. Since the original author of the code is no longer available, I can only guess why it was written this way. Probably to avoid duplication or even unintended. Well, it could seem as an elegant solution if you’re familiar with the code, but to other people it’s just an unnecessary pitfall that should be avoided. It’s unintuitive at best, not easy to comprehend and can lead to nasty bugs, especially if it’s unintended behaviour. That’s why Kotlin, Rust, Zig and other modern languages avoid breaks in their alternatives to switch statements in the first place.

I’m using Spring’s ResponseCookie class as base for the DSL as it has a builder already on-board.

A little example:

val cookie = ResponseCookie
    .from("cookie name", "cookie value")
    .httpOnly(true)
    .path("/")
    .build()

What would this look like with a micro DSL?

val cookie = createCookie("cookie name", "cookie value") {
    httpOnly(true)
    path("/")
}

Instead of calling the static method ResponseCookie.from() which returns a ResponseCookieBuilder object, you just give the function three parameters: two strings for name and value, and a trailing lambda with the builder context. There is also no need to call ResponseCookieBuilder.build() anymore. It’s shorter and better to read. Since this is only a small example the advantages are not that big. Micro DSLs really shine with large and often used builders. They can also help to automate things, see below.

How?

fun createCookie(
    name: String, 
    value: String, 
    lambda: ResponseCookieBuilder.() -> Unit
) = ResponseCookie.from(name, value).apply(lambda).build()

Et voila, a new micro DSL is born. Deriving the trailing lambda function from ResponseCookieBuilder does the trick. The lambda function takes an instance of ResponseCookieBuilder as context of this, so it’s possible to access the methods of the given ResponseCookieBuilder inside the lambda function. All we have to do is to create an instance of ResponseCookieBuilder with ResponseCookie.from() and call Kotlin’s apply method on the builder object with the lambda function. It will automatically inject the current instance of ResponseCookieBuilder into the lambda function and apply the instructions inside the lambda function on the instance. To create a ResponseCookie object from the builder, just call the build method and return the result.

You can use this little trick with all builders. Need more automation? No problem! In my current project we’re using such micro DSLs to create product configurations. The factory method contains sanity checks after the lambda function was applied to the builder object. It will also fetch a YAML file via the product ID given to the builder. This data is parsed into an object and will be put into a property of the builder object. After the configuration object is created, the factory method will add it to a map and return the instance to store in a variable. It’s now possible to directly access the configuration via its variable name or to fetch it from the map. The variable is very useful for tests, but if we have to fetch the configuration dynamically by ID from a string, the map is the way to go.

Of course there are other ways of achieving such automation, but the micro DSL approach is simple, improves readability and can also reduce redundant code. You can even easily nest builders to create a more powerful DSL. Spring’s Kotlin extensions also rely on micro DSLs and extension functions. Take Spring Security for example. Their fluent interface for the security configuration is awful to read and difficult to understand, but Spring also provides a Kotlin extension with a micro DSL for that. So much more intuitive and better to read. There are many more extensions like for bean creation, the MVC mock in tests etc.

Actually I wanted to use Kotlin for a while now, but there were only minor tasks within the Java part of the project. That finally changed and we can focus to improve the Java backend drastically.

Part of this process was a library update. We decided to upgrade JUnit from 4 to 5. A big pain in the ass. I don’t think, I would do it again. JUnit 5 was also part of a bigger problem, even if it was actually PEBKAC.

Kotest and MockK features

If you already know about Kotest or want to know more about the problem I had, just skip to the next headline. The Kotest introduction is a little bit longer.

As I dived more and more into Kotlin, I stumbled over Kotest. A really neat testing framework for Kotlin. There’s nothing wrong with JUnit, but Kotest gives you way more awesome ways to structure your tests.

A little example:

package io.webcodr.demo

import io.webcodr.demo
import io.kotest.assertions.throwables.shouldThrow
import io.kotest.core.spec.style.FunSpec
import io.mockk.*

class UserServiceTest : FunSpec() {
    private val userRepository = mockk<UserRepository>()
    private val service = UserService(userRepository)
    private lateinit var user: User

    init {
        beforeTest {
            user = User(1, "Jane", "Doe", "jane@doe.com")
        }

        afterTest {
            clearAllMocks()
        }

        context("getUser()") {
            fun verifyRepoCalls() {
                verify {
                    userRepository.findById(1)
                }

                confirmVerified(userRepository)
            }

            test("should succeed") {
                every {
                    userRepository.findById(1)
                } returns user

                service.getUser(1).shouldBe(user)

                verifyRepoCalls()
            }

            test("should fail") {
                every {
                    userRepository.findById(1)
                } throws UserNotFoundException()

                shouldThrow<UserNotFoundException> {
                    service.getUser(1)
                }

                verifyRepoCalls()
            }
        }
    }
}

Kotest offers several different styles to write tests. I chose the FunSpec style for this example. You could also use a BDD-like or Jasmine-like style, if you want to.

It’s much more intuitive to nest tests with Kotest. To be fair, JUnit 5 allows you to use @Nested with an inner class to accomplish nesting as well, but it’s not as intuitive and harder to read than trailing lambdas.

Assertions are also a little easier to write. Kotest has over 100 different matchers. You can use them as extension functions, like in the example above or alternatively as infix functions, for example service.getUser(1) shouldBe user. It’s also quite simple to write custom matchers.

There are many more features like soft assertions, tagging, easy temporary file creation or handling for non-deterministic test cases.

For mocking we decided to use MockK, since it’s way more intuitive to use than Mockito with Kotlin. Don’t get me wrong, Mockito is a great library, but it has one flaw: the when method. when is a keyword in Kotlin and to use it with Mockito, you need to write it in backticks. That’s quite ugly and not intuitive at all.

So, in summary, Kotest offers a bunch of pretty neat features and is very intuitive to use. Of course, JUnit can achieve much of this as well, it’s just not that shiny and little harder to read.

The actual problem or: why the frak is there IntelliJ in the title?

If you migrate an old codebase to Kotlin and want to use Kotest, you will have no choice and have to use JUnit and Kotest in coexistence.

That shouldn’t be a problem, since Kotest uses the JUnit 5 Jupiter engine under the hood. But …

As I wrote a new service in Kotlin and some tests with Kotest, I could not start the JUnit tests anymore. As soon as the maven dependency of Kotest was present, IntelliJ didn’t recognize JUnit tests and used the Kotest files only. With mvn test (Maven Surefire) everything worked fine.

I tried several things and was ready to give up. Search engines didn’t find anything about this problem. Nothing on GitHub, nothing on Stack Overflow.

I hate to give up, so I decided to create a small demo project to open a GitHub issue. Well, that didn’t work out as intended, since the discovery of JUnit tests in the demo project worked fine. The IntelliJ JUnit runner did what it was supposed to: run JUnit and Kotest.

Well, frak. There must be some kind of configuration problem with my real project. I already looked at the IntelliJ runner config, Maven files etc. — nothing worked.

I compared the Maven files from both codebases and there was one difference: my real project did not include the JUnit Jupiter Engine dependency. Bingo. I added it to the Maven file and guess what? It worked like a charm.

What an embarrassment. As we upgraded from JUnit 4 to 5, we forgot to add the new dependency for the engine. I don’t know why the tests worked at all, but it seems the engine is not really necessary for all cases. But it can screw up test discovery quite well, if you forget it.

The dependency configuration in the POM file should look like this:

<dependency>
    <groupId>org.junit.jupiter</groupId>
    <artifactId>junit-jupiter-api</artifactId>
    <version>${junit.version}</version>
    <scope>test</scope>
</dependency>
<dependency>
    <groupId>org.junit.jupiter</groupId>
    <artifactId>junit-jupiter-engine</artifactId>
    <version>${junit.version}</version>
    <scope>test</scope>
</dependency>

Well, that was a long post, but IMO it was necessary to show how this problem came to be and even if you have no trouble at all, perhaps you’ll consider using Kotest. It’s awesome!

Gradle

I’m not sure, but this issue could happen with Gradle as well, when you are migrating to JUnit 5.