A standard unit testing problem is how to unit test code that has a dependency on dates or times. Consider a method that returns a greeting according to the time of day. If we were to call this method from a test fixture (say JUnit), it would return different values depending on when the test was run. This is not ideal. Unit tests should pass or fail consistently.
Here’s a simple solution for testing time based code.
In previous articles, I’ve described how to test System.out with JUnit and how to test log4j with JUnit. This article describes how to test log4j2 logging with JUnit. This largely follows the same technique as testing log4j logging but using the the newer log4j2 APIs. Differences between log4j and log4j2 log4j2 follows a similar design read more
Following a recent article on how to Test System.out with JUnit, here’s a follow up on how to test log4J with JUnit. This article describes a technique to test log4J output in a JUnit test by adding a custom appender. This allows us to verify that log4j output contains expected Strings.
JSPs compile to Java code at run time. This is helpful if we want to test code changes without a build and deploy. However, if errors are introduced, they may not be spotted till it’s too late. A useful compromise is to validate JSPs at build time to verify that they will compile. The validator catches syntax errors before the application deploys and starts. This speeds up our build and test cycle and prevents silly mistakes slipping through to production code.
Thymeleaf is a popular templating engine, particularly with Spring projects. Spring Boot has chosen Thymeleaf as the view technology of choice, largely replacing the need for JSP. With old JSPs, custom tag libraries provided integration with various technologies, including Spring Security. A similar library exists to integrate Thymeleaf and Spring Security – the Thymeleaf Spring read more
It can be useful to verify output to System.out in a unit test. For example, if you’re testing application logging or if you’re using log output to sense some other behaviour. It can be tricky to properly mock behaviour of System.out but fortunately, it is possible to test System.out using JUnit.
Spring Boot Actuator provides assistance for application monitoring. Out of the box it provides information on application health, configuration and logging. It’s trivial to enable: simply add the spring-boot-starter-actuator dependency to a Spring Boot project in Maven or Gradle and it just works! The monitoring information is provided as JSON from HTTP endpoints or via JMX.
The Spring Boot Actuator trace endpoint is particularly handy. By default it shows the last 100 HTTP requests made to the application. This article walks through an Actuator demo and shows some of the configuration options to get the best from this feature.
Like a many things in Tomcat, there are a number of ways to enable remote debugging. Here’s the easiest way I’ve found to enable remote debugging in a Docker container running Tomcat.
The wonderful docker-maven-plugin from Spotify is a great way to build Docker images from Maven. If you bind it to Maven phases, it can be used to make a one-step build of a project artifact and its Docker image. For example, if you bind the Docker Maven plugin’s build goal to the Maven package phase, read more
The documentation provided by Spring on deploying a Spring Boot application as a Windows Service is a little sparse. Indeed, here it is in full:
Spring Boot application can be started as Windows service using winsw.
A sample maintained separately to the core of Spring Boot describes step-by-step how you can create a Windows service for your Spring Boot application.
— From Spring Boot Reference Guide (version 1.4.3), section 56.2: Microsoft Windows Services
As the official reference guide is lacking detail, here is a step by step guide to building and deploying a Spring Boot application as a Windows Service.
