Thoughts on agile software development
This year I took part in Advent of Code for the first time. Advent of Code is an exciting and challenging annual competition in which a task has to be solved every day from December 1st to December 25th. The task can be solved using any programming language such as Java, Typescript, Python, Rust, SQL … Read more
The title of this article is no mistake. Anyone who has looked at the FreshMarker Random plugin recently will probably have discovered the new sentence and paragraph built-ins. These two bilt-ins support the library with the generation of the famous Lorem Ipsum pseudo-texts. Without delving deep into history, the Lorem Ipsum texts are a corruption of a Cicero text and serve as dummy texts.
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.
Anyone who has ever worked with Web APIs, and who hasn’t, will be aware of the difficulties of testing in an API environment. When testing an API, there are two sides to consider, that of the producer and that of the consumer. If both do not work hand in hand, then problems are inevitable. Consumer contract tests are designed to avoid some of the difficulties in API testing.
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.
Hin und wieder entdeckt man als Software Entwickler ein Feature in einer Bibliothek wieder, dass man schon zweimal vergessen hat. Wenn man dieses wiederentdeckte Wissen mit einem Kollegen teilen kann, dann ist es nicht nur schön sondern verbessert auch noch die Qualität der täglichen Arbeit.