Mutation testing in Maven & Sonarqube
Introduction
You might have heard about Mutation Testing before. In the last 5 or 6 years it’s been a reasonably hot (“warm”?) topic to discuss in blogs and dev talks. So what is the added value over code coverage with just Unit Testing? Even if you could pride yourself with over 90% line and branch coverage, that coverage means nothing apart from that unit tests are touching production code. It says nothing about how well that code is tested, it doesn’t care whether any asserts exist in your tests. Imagine an engineer that tests a power drill he designed on a sheet of paper, and declaring that it does exactly what it was designed for: drilling holes. It’s obvious that this test is meaningless for a power drill that is meant to be used on wood, steel or stone.
Gradle Goodness: Generate Javadoc In HTML5
Since Java 9 we can specify that the Javadoc output must be generated in HTML 5 instead of the default HTML 4. We need to pass the option -html5 to the javadoc tool. To do this in Gradle we must add the option to the javadoc task configuration. We use the addBooleanOption method of the options property that is part of the javadoc task. We set the argument to html5 and the value to true.
In the following example we reconfigure the javadoc task to make sure the generated Javadoc output is in HTML 5:
Updating Spring Boot and Spring Security
Recently we updated one of our internal applications from Spring Boot 1.5 to 2.1, which includes an update of Spring Security. After the update the OAuth2 security started to fail in the backend, it stopped recognizing the authentication.
The project is an Angular 4 application. It uses angular2-oauth2 (1.3) in the frontend, and spring-boot-security and spring-security-oauth2 on the backend. The frontend is responsible for authentication with our Bitbucket account. This information is then sent to the backend via a 'bearer' authentication token. We have a separate class extending WebSecurityConfigurerAdapter, annotated with @EnableOAuth2Client, to set our security settings.
Gradle Goodness: Rerun Incremental Tasks At Specific Intervals
One of the most important features in Gradle is the support for incremental tasks. Incremental tasks have input and output properties that can be checked by Gradle. When the values of the properties haven’t changed then the task can be marked as up to date by Gradle and it is not executed. This makes a build much faster. Input and output properties can be files, directories or plain object values. We can set a task input property with a date or date/time value to define when a task is up to date for a specific period. As long as the value of the input property hasn’t changed (and of course also the other input and output property values) Gradle will not rerun task and mark it as up to date. This is useful for example if a long running task (e.g. large integration test suite) only needs to run once a day or another period.
In the following example Gradle build file we define a new task Broadcast that will get content from a remote URL and save it in a file. In our case we want to save the latest messages from SDKMAN!. If you don’t know SKDMAN! you should check it out!. The Broadcast task has an incremental task output property, which is the output file of the task:
Should we spike or should we change how we do product backlog refinement?
The Scrum guide by scrum.org doesn’t mention spikes, but it has something else: the Product Backlog Refinement. And this often gets mistaken for a Scrum Event that puts the entire Development Team in a room with the Product Owner for half a day a week. The entire team then looks at the top of the product backlog and tries to uncover all the details there. They do this until enough uncertainties are uncovered and the team feels confident it can estimate. It gets worse when there is a project manager on board who needs estimations to discuss budgets and delivery dates before deciding whether he wants a story at all. This way, you end up spending a lot of time on value you’re not delivering. At some point, somebody will say: This is taking too long; let’s make it a spike and move on. And that’s not what spikes are for.
A spike is a concept from Extreme Programming (XP) where the team does a technical examination of possible solutions before committing to one to solve a requirement. Like many concepts from XP (for example: Daily Standup vs Daily Scrum), it’s found its way into many Scrum projects. The Scrum Alliance adopts and expands the concept by saying it is a story-like backlog item that yields information rather than a working increment of software. This information can be both technical or functional and is deemed necessary before deciding on whether or not to implement a functional story. And if so, it ensures that enough information is available to know how. The Scrum Alliance warns that a spike should be used sparingly, if at all.
Transcoding gRPC to HTTP/JSON using Envoy
When building a service in gRPC you define the message and service definition in a .proto file. gRPC generates client, server and DTO implementations automatically for you in multiple languages. At the end of this post you will understand how to make your gRPC API also accessible via HTTP JSON by using Envoy as a transcoding proxy. You can test it out yourself by running the Java code in the attached github repo. For a quick introduction on gRPC itself, please read gRPC as an alternative to REST.
Once you have a working gRPC service, you can expose a gRPC service as an HTTP JSON API by simply adding some extra annotations to your service definition. Then you need a proxy that translates your HTTP JSON calls and passes them to your gRPC service. We call this process transcoding. Your service is then accessible via gRPC and via HTTP/JSON. I would prefer using gRPC most of the time because it’s more convenient and safer to work with type-safe generated code that follows the ‘contract’, but sometimes transcoding can come in handy:
-
Your webapp can talk to your gRPC service using HTTP/JSON calls. https://github.com/grpc/grpc-web is a JavaScript gRPC implementation that can be used from within the browser. This project is promising but is not yet mature.
-
Because gRPC uses a binary format on the wire, it can be hard to see what is actually being sent and received. Exposing it as an HTTP/JSON API makes it easier to inspect a service by using for example cURL or postman.
-
If you are using a language for which no gRPC compiler exists, you can access it via HTTP/JSON.
-
It paves the way for a smoother adoption of gRPC in your projects, allowing other teams to gradually transition.
Micronaut Mastery: Configuration Property Name Is Lowercased And Hyphen Separated
In Micronaut we can inject configuration properties in different ways into our beans. We can use for example the @Value annotation using a string value with a placeholder for the configuration property name. If we don’t want to use a placeholder we can also use the @Property annotation and set the name attribute to the configuration property name. We have to pay attention to the format of the configuration property name we use. If we refer to a configuration property name using @Value or @Property we must use lowercased and hyphen separated names (also known as kebab casing). Even if the name of the configuration property is camel cased in the configuration file. For example if we have a configuration property sample.theAnswer in our application.properties file, we must use the name sample.the-answer to get the value.
In the following Spock specification we see how to use it in code. The specification defines two beans that use the @Value and @Property annotations and we see that we need to use kebab casing for the configuration property names, even though we use camel casing to set the configuration property values:
Spring Boot: LocalDateTime not parsing to JSON correctly
When creating a Spring Boot Rest service, you can configure Spring to convert a LocalDateTime to display as a ISO-8601 date string when returning a JSON response.
To get this working you have to do a few things.
Firstly, you need the following dependency: com.fasterxml.jackson.datatype:jackson-datatype-jsr310
This dependency has all the JSON serialisers and deserialisers for the Java 8 time API, and when you use Spring Boot with auto configuration, it should load all the correct serialisers. Secondly, you need to add the following to your application properties:
Compliance as code using Ansible
Most companies have security compliance requirements that you need to take into account when creating your software. Similarly to how you can express infrastructure and tests as code, you can shift left security compliance concerns into your development team. This blog shows how a team I worked in used Ansible in a (GitLab) delivery pipeline to create compliant Amazon Machine Images (AMI) containing our application.
There are institutions that have taken it upon themselves to come up with security benchmarks that companies can start from. For example:
-
The Center for Internet Security (CIS) offers benchmarks for oft-used applications and operations systems.
-
The Defense Information Systems Agency (DISA) offers “technical guidance to lock down information systems/software that might otherwise be vulnerable to a malicious computer attack“ through their Security Technical Implementation Guides (STIGs).
Both contain builds of compliant operating systems that you could use as the basis of your machine image. The company I worked for required CentOS 7, and I went and looked for a CIS benchmark for that. The CIS website has a list of hardened images, but I took a different route for several reasons.
-
We had to pick from a predefined list of (hardened) in-company images.
-
I wanted to understand the CIS benchmark and be able to deviate where desirable, for example, if required in order for a COTS application to run.
-
We had to make sure that once our development team was done making changes, the resulting image could be checked once more for CIS compliance. This was part of the compliance requirement for autonomy, meaning that if your team can prove it can manage compliance, it gets the seal of approval.