Focus

testing

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

Cross-platform testing of TypeScript code with Jasmine and Karma

Blog Post

About unit and integration tests

The terms unit test and integration test are typically used as something different, or even opposite. In this blog post I explain why this is misleading and how I prefer to talk about isolation vs. integration instead.

Blog Post

What Could Possibly Go Wrong

What could possibly go wrong if you put Clojure 1.10 and Scala 2.13 on the same classpath? We’re about to find out.

Article

JUnit5 für das Testen von Spring Boot-Anwendungen

Das perfekte Doppel

Podcast

Testen von Microservices

Erfahrungen mit End-to-End Tests

Blog Post

Testen von Microservice-Systemen

Automatisiertes Testen ist in der Softwareentwicklung mittlerweile ein Standardvorgehen. Im Kontext eines verteilten Microservice-Systems wird üblicherweise das korrekte Verhalten jedes einzelne Services mit Hilfe von Unit-, Integrations- und End-2-End Tests verifiziert. Wie aber kann das Zusammenspiel der einzelnen Services getestet und sichergestellt werden? Die Idee, End-2-End Tests des Gesamtsystems zu erstellen, ist naheliegend. Ist dies aber sinnvoll, oder gibt es andere, besser geeignete Ansätze?

Article

Java-Bibliotheken für den Einsatz in Tests

Testunterstützung

Blog Post

Testing is storytelling

Tests do not only exist to verify the absence of known bugs. They’re also documenting the expected behaviour of a system. Moreover, they’re showing developers how to use code.

Blog Post

A Playground for Testing OpenID Connect

This post describes how you can set up a development environment in order to play around with your OpenID client implementation. When running your application in a cluster, it can be difficult to test how it will behave behind a load balancer. One factor that can be particularly difficult to test is when you are communicating with an OAuth 2.0 or OpenID Connect server which expects that a request will be redirected back to the same application instance that it came from.

Blog Post

Spring-less testing

Article

Consumer-Driven Contracts – Testen von Schnittstellen innerhalb einer Microservices-Architektur

In einer Microservices-Architektur entstehen viele Services – potenziell in den verschiedensten Programmiersprachen. Um eine reibungslose Kommunikation zwischen diesen zu gewährleisten, müssen die Schnittstellen passen und auch über längere Zeit stabil bleiben. Consumer-Driven Contracts stellt hierzu einen Ansatz dar, der zudem die Schnittstellen und deren Aufrufer noch zusätzlich testet.

Article

Testobjekt: Geschäftsprozess – Testen für kontinuierliche Verbesserung

Die Automatisierung von Geschäftsprozessen mittels WS-BPEL oder BPMN 2.0 steht in der heutigen Zeit oftmals im Focus der IT-Strategien von Unternehmen. Geschäftsprozesse werden dabei nicht mehr nur fachlich modelliert, sondern so formal beschrieben, dass sie mittels Prozess-Engines ausgeführt werden können. Diese formalen Modelle sind zwar abstrakter und näher an den fachlichen Geschäftsprozessen als normale Programme, sind aber trotzdem Softwareartefakte, die während der einzelnen Entwicklungszyklen und auch bei späteren Anpassungsarbeiten getestet werden müssen.