Maintainable and readable test code is crucial to establish a good test coverage which in turn enables implementing new features and performing refactorings without the fear of breaking something. This post contains many best practices that I collected over the years of writing unit tests and integration tests in Java. It involves modern technologies like JUnit5, AssertJ, Testcontainers, and Kotlin. Some recommendations might be obvious to you, but some might conflict with what you’ve read in books about software development and testing.

Testing classes in isolation and with mocks is popular. But those tests have drawbacks like painful refactorings and the untested integration of the real objects. Fortunately, it’s easy to write integration tests that hit all layers. This way, we are finally testing the behavior instead of the implementation. This post covers concrete code snippets, performance tips and technologies like Spring, JUnit5, Testcontainers, MockWebServer, and AssertJ for easily writing integration tests. Let’s discover integration tests as the sweet spot of testing.

Exceptions are a common mean to handle errors. However, they have some drawbacks when it comes to compiler support, safety and traceability. Fortunately, we can leverage Kotlin’s sealed classes to create result objects that solve the mentioned problems. This way, we get great compiler support and the code becomes clean, less error-prone, easy to grasp and predictable.

MongoDB’s dynamic schema is powerful and challenging at the same time. In Java, a common approach is to use an object-document mapper to make the schema explicit in the application layer. Kotlin takes this approach even further by providing additional safety and conciseness. This post shows how the development with MongoDB can benefit from Kotlin and which patterns turned out to be useful in practice. We’ll also cover best practices for coding and schema design.

Unit Testing in Kotlin is fun and tricky at the same time. We can benefit a lot from Kotlin’s powerful language features to write readable and concise unit tests. But in order to write idiomatic Kotlin test code in the first place, there is a certain test setup required. This post contains best practices and guidelines to write unit test code in Kotlin that is idiomatic, readable, concise and produces reasonable failure messages.

Hibernate is my daily business. And it bugs me. Hibernate adds non-trivial complexity to your application and restricts the flexibility in terms of the query capabilities and the class design. Fortunately, there are many alternatives available. In this post, I like to recap some drawbacks of Hibernate and present an alternative: Do-it-yourself ORM with plain SQL, Spring’s JdbcTemplate and compact mapping code powered by Kotlin.

With Kotlin we can write code that is easy to understand, short, expressive and safe. Sounds like clean code, doesn’t it? In this post, I go through some recommendations and principles of clean code and consider if Kotlin can help to fulfill this rules or not. Moreover, I show restrictions and points, where we should be careful. At the end, I discuss if Kotlin leads to “a dark or a bright path”.

In order to take full advantage of Kotlin, we have to revisit some best practices we got used to in Java. Many of them can be replaced with better alternatives that are provided by Kotlin. Let’s see how we can write idiomatic Kotlin code and do things the Kotlin way.

Coding with Kotlin is great fun. But things are getting really interesting when we try to use Kotlin in conjunction with popular frameworks like Spring Boot and Vaadin. The development with those frameworks can benefit a lot from Kotlin. However, we have to pay attention to some pitfalls.

We at Spreadshirt have started to use the JVM language Kotlin in a couple of services. This ended up in great enthusiasm. Kotlin allows us to significantly reduce the boilerplate and to write more robust and readable code. In fact, I don’t want to write Java anymore. In this post I like to show you why.

Developing with Python was a refreshing and pleasant experience. After working with Java for a while, you may forget how verbose and clumsy this language is sometimes. But Python shows how simple and powerful a programming language can be. Let me show you some examples.

Testing RESTful Web Services can be cumbersome because you have to deal with low-level concerns which can make your tests verbose, hard to read and to maintain. Fortunately, there are libraries and best practices helping you to keep your integration tests concise, clean, decoupled and maintainable. This post covers those best practices.

Java has checked exceptions and is out on a limb. Is there a reason, why other languages like C++, Objective-C, C#, Kotlin, Scala don’t support this concept? What is the problem about checked exceptions and what can we do instead? And most important: What do water wings and checked exceptions have in common? This article gives the answer to all of these questions and shows why unchecked exceptions are the better choice.

From time to time I review code of my colleagues. Especially for a younger developer giving feedback to an older and experienced developer is hard. The colleague has to be open-minded for feedback and criticism. For this, it’s helpful to communicate how code reviews should be considered. I’m convinced that doing so will increase the acceptance of your feedback. But let’s get more concrete.