OpenAPI validation with Robot Framework

Posted on by  
Robin Mackaij

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!

Continue reading →

Detect & delete unreferenced code with ArchUnit

Posted on by  
Tim te Beek

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.

Continue reading →

Spocklight: Use Stub or Mock For Spring Component Using @SpringBean

Posted on by  
Hubert Klein Ikkink

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.

Continue reading →