Util classes are a natural representation of what developers consider a “missing functionality”. Everyone in the Java world has written some. They are so common, that I often see developers new to Kotlin still writing them just as they were used to. Lets see how to take a simple Util class and enhance it with Kotlin in a few simple steps.
Consider domain of establishing connection to external services. You need to express that you work with port and not just any Integer. A Java developer might come up with something like this:
public class PortUtils {
public static Boolean isValidPort(Integer value) {
return value > 0 && value <= 65535;
}
public static Boolean isPortFree(Integer port) {
try (ServerSocket s = new ServerSocket(port)) {
return true;
} catch (IOException e) {
return false;
}
}…
Barcamp 2019 in Hradec Králové has presented me with an oportunity to challenge myself with some public speaking. I decided to prepare a live coding demo and now when it’s over, I’d like to share some tips I learned along the way.
Just do it. There is really no point in postponing the decision. Make the commitment as soon as you can so you still feel enthusiastic about it. This enthusiasm may still fuel early stages of your preparations. That’s pretty much how I decided to show off my TDD (Test Driven Development) skills in Kotlin.
This is actually something I failed to do. I already picked my topic and made a description at presenters registration. What I did not realize was that I should fit my talk in 20 minutes only! If you ever tried TDD, you know that you don’t really go very fast (at least at the beginning) and I also wanted to show some Kotlin features during the talk. I spent a lot of energy actualy trying to fit some meaningful chunk of content into my 20 min long presentation. …
This article does not argue why it is a good idea to write unit tests. Nor does it explain role of unit tests within testing pyramid. The purpose of this article is to show how to setup unit test environment for Kotlin project and efectively test your units using junit, mockito and mockito-kotlin libraries.
This build.gradle.kts is close to what I usually start with:
I use mockito in combination with mockito-kotlin. It is very easy to learn, it’s expressive and readable. Mockito is usable on its own but readability will suffer:
Maybe you have already noticed that I did not include any fancy assertion framework like AssertJ. I acknowledge that such libraries provide very powerful assertions for every occasion, but nevertheless I don’t use them. In most cases, it is desirable to keep your tests as simple as possible. I can do fine with just simple assertEquals and assertTrue in most cases. These are easy to remember, easy to read and easy to understand. …
In order to make my code simple, readable and predictible I actually avoid nullable references. When I review my code, I even consider nullable types a code smell. Of course, this is not an absolute statement. There are definitely some cases when leveraging nullability is totally legit. More often than not however, the nullable types crawl their way into our codebase due to our negligence and we need to be ready to deal with it.
Kotlin is build upon Java and Java types are implicitly nullable. This can oftentimes confuse your IDE (I use IntelliJ IDEA). Lets inspect the following snippet. …
About