Capturing and comparing entire objects with Mockito and AssertJ

Let’s say we have a project in which we have the following classes:

We don’t yet have an implementation of the Runway interface (that will be created by another team), but we would like to test if our code creates a correct Plane object and passes it to the Runway. We’ll be using Mockito to mock the Runway implementation to test only the Airport class (so, write an actual unit test). I really like AssertJ so I’ll be using that one for assertions instead of usual JUnit assertions.

Let’s start with testing if plane departs correctly:

We now know that a plane departed, but we don’t yet know if that was the right plane. Let’s try comparing to the plane we expect:

The result is a failing test – not that we wouldn’t expect that.

There are two separate instances of Plane created here. While their fields are all the same, they are different objects and Mockito’s verify method checks that. Moreover, if we wanted to check only if a specific field of passed object has an expected value, we wouldn’t have an ability to check that with Mockito’s verify. There is a class called ArgumentCaptor though that can help us. Also, AssertJ has a neat method for comparing if all fields of two objects are the same:

The dish is ready to be served, enjoy.

Matchlogger: a slow start

As the Polish-speaking followers (quite likely 100% of all my followers) already know, I am taking part in a software development contest called „Daj się poznać” where the aim is to develop an open-source application for three months and blog about it. The contest starts today, so this is the moment when many participants write about their aims. So, my project is…


A web-based app that can be used by players, referees, and supporters to mark matches they either took part in or watched. The aim is to enable the users to log their matches in various disciplines and add data they deem important, for example, minutes they played, goals they scored, match result, attendance… The idea is based a bit on a now-defunct website called where the functionality was fairly limited and the service closed down a few months ago, but extends it not to include only supporters and only of teams that play in higher leagues.

As for the technology stack – Spring Boot is my backend choice for this project. I still consider several options for the frontend, but one that is now on my spotlight is Vue.js. I’ll likely decide on the approach here in several days. The database will be using MySQL.

First steps are already done. Today I set up the project using Spring Initializr. While most chosen dependencies were fairly standard, the one that required some extra configuration was Liquibase – the library for database versioning which I’m going to use from the very beginning. As often with Spring Boot, also this time it was a one-liner in the configuration file. The empty changelog file also was needed to be created at the referenced location.

After today, the application can be run using mvn spring-boot:run and starts up correctly with Basic auth as default security setting. Not much can be seen, though:

The code is available at Github. I’ll be using Github issues to take care of the backlog and Toggl for time logging. For the first deployment, I want to have a functioning login (likely Google- or another provider- based).