Setting: We serve a GraphQl API using Sangria and Akka HTTP.

We’ll go through the steps necessary to parse value classes.

Testing classes that work with date calculations based on the current date and time (now) can be difficult. First of all we must make sure our class under test accepts a java.time.Clock instance. This allows us to provide a specific Clock instance in our tests where we can define for example a fixed value, so our tests don’t break when the actual date and time changes. But this can still not be enough for classes that will behave different based on the value returned for now. The Clock instances in Java are immutable, so it is not possible to change the date or time for a Clock instance.

In Spock 2.0 we can use the new MutableClock class in our specifications to have a Clock that can be used to go forward or backward in time on the same Clock instance. We can create a MutableClock and pass it to the class under test. We can test the class with the initial date and time of the Clock object, then change the date and time for the clock and test the class again without having to create a new instance of the class under test. This is handy in situations like a queue implementation, where a message delivery date could be used to see if messages need to be delivered or not. By changing the date and time of the clock that is passed to the queue implementation we can write specifications that can check the functionality of the queue instance.

We’ll update a config file with sed

This short story is all about the absolute joy you can experience as a Developer. I wrote it to share what it is that I miss sometimes, now that I’ve taken on a different path these last years. I wanted to write it down to share a combination of feelings that I miss that other developers might recognise as well and can cherish even more because it is written down. Hopefully this blog brings a smile to your face if you’re a developer, and can even be something that you can rely on in darker times. When those blasted builds just won’t go green, tests won’t pass, or production is not the happy place that it should be.

After completing the Kotlin for Java Developers Course on Coursera I was looking for an excuse to put my freshly gained Kotlin knowledge into action. I decided to address my frustration about the large amount of falsely detected movements by one of my security camera’s.

One of the core components of that solution is a REST API that receives an image and returns a list of detected objects. I decided to develop that using Kotlin, KotlinDL and KTor.

This blog posts describes the core components of the solution. The source code of the example is available at GitHub.

This post will show how to create a list with how many products there are in a category and their sub categories with Elasticsearch aggregations covered with tests.

On our site there are products with a category and they have a sub category, for example product category is shoes and sneakers is a sub category.

Many JSON REST APIs today offer a Swagger page as documentation as a way to explore the API (see also this recent post by Jorrit). This Swagger page (aka Swagger UI) is often used by testers to interact with the API to manually construct and verify the API calls that are then implemented as an automated test.

What you may not realize, is that the Swagger UI is generated from an openapi.json or openapi.yaml file hosted by the API server. To ensure "Swagger compatibility", this must follow the OpenAPI Specification.

But if a webpage that can interact with the API is generated from this document, shouldn’t it be possible to generate test cases for this API from it also?

Let’s find out!

For one of our clients we use the Quarkus framework. Quarkus is a full-stack, Kubernetes-native Java framework, designed to work with popular Java standards, frameworks and libraries. It is possible to get into details about Quarkus, but that’s not what this post is about! This blog will tell you how to set up a simple database driven application with a full end-to-end test, using Quarkus and testcontainers.

In my previous post I showed my git and vim configuration. This post will be about random small tools that I use, such as tooling for docker and kubernetes, or just some small utilities to make life a bit easier.

In my previous post I showed you my terminal and shell, with some of the configuration I like to use. This post of 'A Developers Toolbox' will be all about git and vim. I will show you the aliases I use, how you can set up git hooks, and a useful tool to view your git log. And I will share my vim configuration, with some tips and tricks on how to use it.