Blog & Artikel von Torsten Mandry

Blog-Post

Test organization and naming

As our system grows, so will our test suites. For our production code, we have learned techniques to keep it maintainable. For example, we try to structure our logic into sub-aspects, put them in specific locations and give the units meaningful names. We want to achieve the same for our tests. One of the main goals is that a developer - or generally speaking, the person who has to maintain the test - knows where to find which test. We also want to understand as quickly as possible what the test is for and what might be the reason for a failing test.

Blog-Post

Test Strategy

In our previous posts, we focused on why and how we write tests. In most of our projects, there will be many of those tests. In the last post about tests granularity, we additionally stated that there usually will be different kinds of tests, on different levels of granularity. That leads to our next topic: which kinds of tests do we need and what is the ideal mix of them?

Blog-Post

Tests Granularity
Blog-Post

Anatomy of a Good Test

In our last post, we focused on why we should write tests and what value they provide. This time we will go far more technical and take a look at a single test. We will show what makes a test a good one and describe desired and unwanted properties. Interestingly enough, all those properties hold, no matter how isolated or integrated the test is. This already gives us a hint that all tests are alike, we should remember that. Unfortunately, as the topic is very broad, we will have to skip some aspects that play a role when we’re talking about test suites. We will get back to them in one of our next posts.

Blog-Post

Why you should write automated tests

This blog post gives an overview of the most common benefits gained by writing automated tests. It starts in a place where most of the projects we’ve seen so far are: tests are written as a last step of the development process. Then it shows additional benefits that could be gained if we all gave the tests a bit more focus and care.

Blog-Post

Visualizing the progress of a refactoring into a hexagonal architecture using jQAssistant
Blog-Post

Cookie-based Spring Security Session

If you need authentication within your Spring Boot web application, the natural choice is to use Spring Security. It’s easy to use and, as long as you stick close to the defaults, it’s also quite easy to configure. But, by sticking to those defaults, you will automatically get a session that is persisted on the server-side. That’s a problem.

Blog-Post

Scraping a Docker Swarm service with Prometheus

Scraping a Docker swarm service from a Prometheus server that is outside the swarm is not as easy as it might look at a first glance. You have to fetch the metrics of all running service instances, but how to identify and access them?

Blog-Post

About unit and integration tests
Blog-Post

code-your-model

Some time ago I was looking for some simple, lightweight tool to document a complex, modularized model. I was not able to find anything that fits my requirements or expectations, so I came up with my own idea. Today, a good 15 months later, I want to introduce it to you.

Blog-Post

Prometheus Counters and how to deal with them

In this article, I want you to join me on my way to understand how Counters in Prometheus work, and how to query them to get the right information.

Blog-Post

Testen von Microservice-Systemen
Blog-Post

Domain Exceptions?

In jedem Softwaresystem kommt es zu Ausnahmesituationen. In der Regel handelt es sich um technische Ausnahmen, die in Java als Exceptions auftreten und behandelt werden. Gibt es aber auch fachliche Ausnahmen, also quasi „Domain Exceptions”? Und ist es sinnvoll, diese in Java als Exceptions zu modellieren? Einige Beispiele aus einem Kundenprojekt zeigen, dass dies häufig nicht der Fall ist.