Skip to content

Category: Testing

Testing System.exit()

Using JUnit for testing System.exit() calls from application code can be tricky. This is because System.exit() terminates the JVM running it. If you’re running JUnit, this is the JUnit runner. If JUnit invokes System.exit() in application code it will end your test without deciding a success / fail status and will also terminate the test run.

Testing Spring reactive WebClient

Spring WebClient is the reactive replacement for the legacy RestTemplate. It has a more modern fluent API and first class support for Reactive Streams. This means it supports non-blocking, asynchronous responses.

However, the reactive WebClient does not yet have the mature test support that RestTemplate now has. There is not yet a standard recipe to test Spring WebClient applications. No doubt support will be improved in future versions but for now, here’s what works for me.

Unit test time based logic

A standard unit testing problem is how to unit test code that has a dependency on dates or times. For example a method that returns a greeting according to the time of day:

public String timeOfDayGreeting() {
    LocalTime now =;
    if (now.isBefore(LocalTime.NOON)) {
        return "Good morning";
    } else if (now.isBefore(LocalTime.of(18, 00))) {
        return "Good afternoon";
    } else {
        return "Good evening";

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.

Test First React part 1: setup and first tests

React is a great choice for writing test first client side Javascript. The test ecosystem is mature enough to enable test first development of complex components. This article shows how to build a React component test first and introduces supporting test libraries Jest and Enzyme. In the next article we’ll look at more advanced testing including API testing and module mocking.

Test System.out with JUnit

Edit: see also the follow up article on how to Test log4j with JUnit if you’re interested in specifically testing log output.

Just occasionally, 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 with JUnit.

User Impersonation with Spring Security SwitchUserFilter

A common requirement for secured applications is that admin / super users are able to login as any other user. For example, it may be helpful for a customer support analyst to access a system as if they were a real specific customer. The obvious way to do this is for the admin user to ask for the customer’s password or look it up in the password database. This is usually an unacceptable security compromise – no one should know a customer’s password except for the customer. And if the password database is implemented correctly it should be technically impossible for anyone – not even a system admin or DBA – to discover a user’s password.

An alternative solution is to allow admin users to login with their own unique username and password but allow them to then impersonate any other user. After the admin user has logged in, they can enter the username of another user and then view the application as if they were logged in as that user. Implementing user impersonation in this way also has the advantage that the system knows who has really logged in. If the system has an audit log, we can audit actions against the real admin user, rather than the impersonated user.