Thoughts on agile software development
In previous articles on JUnit 5, various mechanisms were presented with which the JUnit tests could be made clearer. In this article, the ArgumentsAggregator is presented as an additional helpful mechanism.
When updating some libraries that use FreshMarker, I was a bit surprised. The Hamcrest Matcher Generator library was still using Freemarker and also the library has never been published on Maven Central. Two things that should be fixed as soon as possible.
The moment is a wonderful thing, but not for software developers, because it keeps on moving. How can you write a test if the value changes with every test run? Functionality has always been an abomination that concealed some form of now. In FreshMarker, for example, this little monster can be found in the built-in variable .now.
FreshMarker is strongly characterised by KISS and YAGNI. This makes the template engine lean and yet powerful. But in some places, the simplicity leads to careless mistakes.
In the first versions, the system variable .version was defined as a constant for the FreshMarker version. Unfortunately, this meant that the version number was regularly forgotten to be updated before the release.
While implementing some tests for the Freshmarker 1.0.0 release, I discovered another interesting possibility for a JUnit 5 TempDirFactory implementation. But first things first.
FreshMarker is an embedded Java template engine that focusses on extensibility and simplicity. For this reason, every implementation of an extension is associated with weighing up its pros and cons. For a long time, the import directive therefore remained an unrealised feature.
When I first heard about mutation testing, I was – to put it kindly – very confused. The idea that we change our code to see which tests fail doesn’t look particularly promising at first glance. But if you take a closer look at the approach, you realize the potential it holds.
It is always instructive to look at well-known open source projects to learn from the implementation used. Sometimes you look at the unit tests and start to wonder. A serious problem with large and old frameworks is the time-consuming adaptation to changing environments. Modern features in libraries such as JUnit 5 simplify the code base immensely.
The JUnit 5 test library offers a wide range of options for extending the framework and thus simplifying the work of software developers. One of these options is the DisplayNameGenerator, which can be used to modify the generation of test names in the console output. When creating exercises for a course, I was surprised to find that there is a DisplayNameGenerator that replaces underscores with spaces, but none that handles the camel case form. Fortunately, this can be changed.
The article Bug Pattern in Eigenbau showed how easily the Error Prone catalogue can be expanded with your own Bug Patterns. However, it failed to mention what unit tests for such Bug Patterns look like.