In a previous blog post we looked into how to get started with Diffblue Cover. In this post, we will focus on utilizing Diffblue Cover to generate tests for a pre-existing project that contains untested code.

I find the best time to write tests to be as you write the code but, sometimes we discover untested code in our projects. Fully understanding someone else’s code that does not have tests written for it can be difficult and quite time-consuming. Let’s try out Diffblue Cover to see if it can help us.

Diffblue Cover is an AI-powered software testing tool that generates unit tests for Java code. Tests can easily be generated directly from your code using the Diffblue Cover IntelliJ plugin. Let’s get started by setting up Diffblue Cover and start generating tests.

Many JSON REST APIs today offer a Swagger page as documentation as a way to explore the API (see also this recent post by Jorrit). This Swagger page (aka Swagger UI) is often used by testers to interact with the API to manually construct and verify the API calls that are then implemented as an automated test.

What you may not realize, is that the Swagger UI is generated from an openapi.json or openapi.yaml file hosted by the API server. To ensure "Swagger compatibility", this must follow the OpenAPI Specification.

But if a webpage that can interact with the API is generated from this document, shouldn’t it be possible to generate test cases for this API from it also?

Let’s find out!

When you maintain a large Java project for a longer period, the moments where you’re finally able to remove unused code can be very satisfying. No more upkeep, library version migrations or dark corners to maintain, for code that’s no longer being used. But finding out which parts of the code base can be removed can be a challenge, and tooling in this space seems not to have kept pace with recent development practices in Java. In this post we’ll outline an approach to find unreferenced code with ArchUnit, which allows you to iteratively detect & delete unused code from your Java projects.

The December 2019 release of Apache Kafka 2.4.0 saw usability improvements in TopologyTestDriver, with the addition of new TestInputTopic and TestOutputTopic classes. These offer typesafe methods to easily produce and consume messages for your Kafka Streams tests. In this post we’ll explore these new classes in the context of Avro messages, which requires a small trick to get working.

When we write tests or specifications using Spock for our Spring Boot application, we might want to replace some Spring components with a stub or mock version. With the stub or mock version we can write expected outcomes and behaviour in our specifications. Since Spock 1.2 and the Spock Spring extension we can use the @SpringBean annotation to replace a Spring component with a stub or mock version. (This is quite similar as the @MockBean for Mockito mocks that is supported by Spring Boot). We only have to declare a variable in our specification of the type of the Spring component we want to replace. We directly use the Stub() or Mock() methods to create the stub or mock version when we define the variable. From now on we can describe expected output values or behaviour just like any Spock stub or mock implementation.