With AWS CDK, you can practice infrastructure-as-code using your programming language of choice. Since this code is setting up cloud infrastructure, many classical unit testing approaches are not feasible. Adding Approval Testing to your project can increase confidence and safety.

Examples here will use Java, but the principles work in any language, and appropriate libraries are available.

Approval Testing

With Approval Tests, you take a snapshot of the output of your code, and verify that this output is consistent with earlier results. If the output has not changed, the test passes. The expected output is not expressed in source code but stored as data in a file. This is also shown in the example on Approvals:

For my full-stack projects I like to use Server-Side rendering with Javalin, j2html and htmx. Together, these libraries allow you to write interactive full-stack web applications in vanilla java. In this post I’d like to explain how the j2html library fits in this setup, go over a few benefits, and link a converter that I wrote to make building the user interface easier.

Server Side Rendering

While the last decade was dominated by client-side frameworks, many applications could perhaps have saved a lot of development time by using server-side rendering. This means that the resulting html is built on the server, including its data, styling and behaviour.

Writing tests on asynchronous code can be a challenge. Given an asynchronous process to test, we may try to use custom code to wait for the process to finish or reach a certain state. This may cause us to end up with tests that are flaky, slow, or hard to understand. It is not uncommon for legacy projects to have these setups, and perhaps they can be improved a little.

This website was made using Hugo, following the quick start tutorial and iterating from there. So far its been a lot of fun, and gradually expanding website functionality has been a very natural process.

Content

I use Obsidian to create my content, allowing me to write using MarkDown. Using Obsidian Linter I can automatically insert YAML properties that Hugo will pick up as metadata. Using this setup there is a nice separation between site content and site functionality.

Writing code assuming everything will follow the happy path may not result in the best software quality or user experience. Sometimes we choose to ignore unhappy paths, or lack awareness of the existence of unhappy paths. Both of these scenarios can lead to runtime bugs and problems for customers which may be good to prevent.

Many strategies and coding styles exist in different languages to give the developer tools to address this issue. In this post I’d like to explore some of them and illustrate my preferences.