Should you collect and measure code coverage on integration tests or only unit tests? In this post I’ll share some thoughts on this topic.
I’ve been working lately on a project with a few services (or microservices, if you like to play buzzword bingo). I wanted to share some thoughts on how using Swagger together with MapStruct can make things easier.
Following up the previous post about swagger, in this post I’m using the maven plugin version of swagger code generator.
exclude configuration works with classes, so the
.class extension is relevant in specifying the path.
<plugin> <groupId>org.jacoco</groupId> <artifactId>jacoco-maven-plugin</artifactId> <version>0.8.1</version> <configuration> <excludes> <exclude>com/acme/models/Spring*</exclude> <exclude>com/acme/api/*Api.class</exclude> <exclude>com/acme/generated/**/*</exclude> </excludes> </configuration>
In this post, I’ll be using Swagger to build a REST API with Java and Spring Boot. Swagger is an API framework. It uses a YAML-based language to define an API and it has a code generator that supports multiple languages.
In this post I’m using the Maven Enforcer plugin to break the build when certain files don’t follow the expected naming convention. It’s always a good idea to take the time and implement these checks inside the build pipeline. The alternative is hoping that code reviewers will spot the problems, which is a manual, tedious and error prone approach. Automate all the things! Continue reading Validate filename conventions with Maven Enforcer plugin
A little bit more than a month ago, I created an improved Maven archetype project. Similar to the default quickstart archetype, but for Java 8 and with recent jUnit dependency. In order for someone to use it, they’d have to clone the repo, as I had not published it in Maven. After a bit of studying, I figured out what is needed to make the package public. More importantly, I implemented the process in Travis, so that a new version gets published automatically.