Code-Held

I a project I worked on I saw that nearly every entity and value object was created with Lomboks @Builder. Their reason is that it makes it easier to construct these objects - especially for tests. But it comes with a cost. The problems that these builders create can’t be detected by the compiler and are especially dangerous in every CI environment.

Unit tests had a bad reputation in many teams I worked with. To my confusion I even experienced that a team wrote a hell lot of integration tests but rarely any unit tests. This is contrary to the well-known testing triangle, and surprised me quite a bit. The reason - as I was told - was the experience of the team. “When you change something you have to adapt many unit tests”, was the common tenor. So they decided to write integration tests which call the real endpoints instead. This comes with a cost. Generally you have a harder time to identify where a issue lies when an integration test - which goes through the whole system - fails. Also the runtime will not lead to fast feedback - one of the main benefits of having proper unit tests. I discovered that the issue is that many developers never learned how to write proper unit tests. In this post I will cover the best practices that I developed throughout my career.

Spring Data provides an easy way of keeping track who creates and modifies a persistent entity as well as when the action happened by annotating properties with @CreatedBy, @CreatedDate, @LastModifiedBy and @LastModifiedDate. The properties are automatically provided by an implementation of the AuditAware and DateTimeProvider interface.

I work with Jenkins Pipeline for three years now and one pain point is proper isolation of shared functionality between pipelines but even steps. In our repository we defined multiple pipelines and some are that large that we share functionality within it. Jenkins offers the possibility to create shared libraries for that purpose. But unfortunately it’s not possible to load it from the same repository. Since many of the changes in the pipeline are related to a change of the shared library it was tedious to match the branches and versions to be backward compatible. What we actually wanted is having the shared library in our main repository so the states of the pipeline is pinned to the state of the main repository. And we finally figured out how to do (hack) that.

In this post we’ll go through an example application and see which methods and principles we can apply to build a robust application that is easy to maintain, extend, understand and use. In general, this is a subject with a much larger scope than a simple blog post can provide, so the content is neither complete nor exhaustive, but a selection of topics that I visited recently. We use an arbitrary business case where we can buy and sell resources on a market. Our example is implemented with Java using Spring Shell for a simple frontend representation. However, please keep in mind, even if technology you use operates differently, the principles stated in this post remain true for every language. Without further hesitation let’s start with an example of how our application works:

At some point it hits everyone. Your precious work of several hours is vanished because of a hardware failure. For that the industry came up with several solutions like the idea of version control systems. But recently I was dumb enough to not do any commit for several hours - just to leave the history clean. Big mistake… But did you think about automating that? How about committing every couple of minutes automatically? In this post I’ll explain this - on the first sight - weird workflow.