More and more companies are switching over to cloud native environments. As a developer this gives me a lot of services to create awesome applications. The challenge that occurred to me right away was how to use all those new components during development, since some companies do not have a testing/development environment in their cloud provider to play with. LocalStack piqued my interest to simulate an AWS environment locally on my laptop, or when running the CI/CD pipeline.
Adding code coverage to SonarQube is quite easy for any Maven project nowadays. Just add the jacoco-maven-plugin dependency to your pom.xml, add the
prepare-agent execution task, and you are good to go. Even for multiple modules this works out of the box. But time goes on and your application grows as well. You start moving code to other modules, and somehow SonarQube no longer seems to pick up the covered code. What the heck is going on?
MongoDB, or Mongo compatible DocumentDB, saves their data in Binary JSON (BSON). They used to save their UUIDs as binary subtype 0x03, but the interpretation was not similar in a multi-platform environment and caused issues. Therefore, the 0x04 was introduced.
Spring Boot Admin describes several ways of connecting clients to the admin server. If your Spring Boot applications are running on kubernetes or openshift then Spring Boot Admin can use the Spring Cloud Kubernetes discovery client. In this blogpost i’ll show you how.
I’ve recently had the situation where I deployed a Spring Boot application on OpenShift where a certain dependency needed a properties file that couldn’t be found. The problem was that this dependency didn’t scan the classpath for the file, but just opened a FileInputStream relative to the current path.
On OSX and Windows, as you might know, directories are case insensitive. So the directory CaseSensitive and casesensitive are the same on those operating systems. But on Linux, they are different directories.
While I’m working with Terraform, I’d thought I’d share the way I set up my DNS for my Virtual Private Cloud (VPC).
Separating concerns is something we as developers are used to thinking about in terms of code. But the same also applies to identity management. If you’ve dabbled in AWS, you can get started right away with a root account. However, when it goes beyond dabbling, it might be a good idea to start splitting up responsibilities.
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.
Mutation tests aim to expose tests that cover the lines they’re meant to cover but are insufficient in testing the intent of the code. The idea behind this is fairly simple: introduce “mutants” in the code that is being tested, and check whether the unit tests that cover these mutants still succeed or start to fail. If a test still succeeds, that means the test falls short of verifying the complete intent of the code!
So what is a “mutant” in this case?
Most of the time, it’s as simple as an operator
+, -, &&, || etc., that is “mutated” into a different one.
In this way, a mutation testing framework helps to identify code that is not tested sufficiently and identifies weak tests that still succeed when mutants are introduced.
If this is something you consider to be a valuable addition to your project, consider trying out Mutation Testing by following the guide below.
In this blog post, I walk through the steps of configuring and using the mutation testing framework PIT for a Java codebase and explain how to integrate it with the code quality inspection platform SonarQube.
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: