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.
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:
Continue reading →
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.
Continue reading →
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:
Continue reading →
