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.
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.
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 = 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.
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…
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.
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.
I’ve been looking a lot recently at JUnit (and TestNG) tests on a code base I’m not too familiar with. In many cases I was not convinced that the tests were adequate but it took a fair bit of investigation before I could be satisfied that this was the case. I would need to look at the tests, then look at the code it’s meant to exercise, then try to work out in my head if the test covers everything it should. To make this process a bit easier, I’ve started running code coverage analysis using Emma. While this doesn’t tell me if the test is good or not, it does show me at a glance how much code is covered by the test and exactly which lines, methods and classes are missed. This is usually a good first approximation for the quality of the test case.
I’ve found Emma to be a useful tool to run after I think I’ve written my test cases and got them working. Running the test case tells me if the code being tested works. Running Emma tells me if I’ve tested enough of the code. There’s no point in having 100% test case successes if the tests themselves only exercise 50% of the code.
I’ve decided to revisit the JUnit testing Hibernate and Spring recipe that I posted a while back. A problem with the previous recipe is that it did not provide any means to initialize the test database. This wasn’t too much of a problem as I was mostly testing the data insert operations of the DAOs. I then used the same DAO to retrieve the newly inserted data and tested what came back. However this is no good if I don’t want insert operations on my DAO (if it’s to retrieve read only data from the database) or if I want to test the retrieval operations independently of the insert operations.
This post extends the recipe to include a means of initialising the database using DbUnit.
Here’s a nice recipe for unit testing Spring configured Hibernate. It allows me to neatly test my Spring configured DAOs and reuse a lot of the Hibernate Session and Transaction configuration beans from my production code. This saves having to rewrite it for my tests and also makes the tests more realistic. I’d rather test my production code rather than use mocks as far as possible.