A. Rothuis

Testing software, whether as specification beforehand or as verification afterwards, is often based on examples. Examples are easy to understand, explain the language of the domain and help illustrate the intended use of the system or unit under test.

However, it can be difficult to fully test a system or unit using examples alone. Coverage alone is not enough. When there are lots of cases that need consideration, there is a risk that edge-cases and certain combinations of inputs are overlooked. In some cases, the sheer amount of possible inputs and outputs make total testing a prohibitive effort.

That is where property-based testing can offer a helping hand. In this post, we will look at the similarities and differences between example-based and property-based approaches to testing and why there is value in combining both. All this against the backdrop of a relatively simple game: Rock, Paper, Scissors.

In lectures regarding object-oriented programming, I sometimes encounter students questioning the use of Java’s interfaces. Why do we need to go through the hassle of defining a class as well as an interface? Once they are convinced (or conditioned) to use them, the questions do not end: students often wonder when interfaces are and are not necessary and how they can contribute to well-designed software.

In this post, we will uncover the power of protocols, a more general term for interfaces, and dive into some common implementations. Along the way, we will discuss why interfaces are useful and how they are commonly used to shape the design and architecture of (object-oriented) software.

One of the primary objectives when designing software is to strive for simplicity. We are reminded of this through acronyms, adagia and our failure to easily comprehend our colleagues’ — or, perhaps more often, our own — code. But what does it mean to “Keep It Simple, Stupid”? And when is software too complex?

In this post, we will explore complexity from the perspective of execution flow in our code. We will have a look at a formal, rigorous method of assessing this complexity and, even though these measures are not novel, they are still worth knowing (and trying out) when striving for quality software.

At the time of writing, there is an ongoing discussion in ECMAScript Technical Committee 39 (TC39) regarding the implementation of a pipeline operator. At the same time, there has been an open RFC in the PHP community regarding a pipe operator since 2016. It seems that multiple communities would like a pipeline operator. But why?

In this post, we will explore which problems a pipeline operator would solve and how other languages deal with these problems.

I have been using Docker for a lot of things. For example, docker-compose is extremely useful for quickly setting up a service-based development environment.

Recently, I had the need to run a command once in a Docker image and do something with the file output. For instance, this is quite useful when encapsulating a compilation step or when processing data from one file to another using a docker image, so a user only needs docker as a dependency and the image does the rest.

In this short post, we will explore using files in one-off docker commands with and without defining a custom Dockerfile.