JCore Blog

Running AWS locally with LocalStack

Posted on by  
Thomas de Groot

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.

Continue reading →

How to fix a drop of code coverage with a multi module Maven project

Posted on by  
Jacob van Lingen

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?

Continue reading →

AWS accounts & users: Separation of Concerns

Posted on by  
Casper Rooker

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.

Continue reading →

Mutation testing in Maven & Sonarqube

Posted on by  
Casper Rooker

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.

Continue reading →

shadow-left