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.
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.
Using code test coverage analysis we’ve got a new metric we can use to judge the quality of our code. As with any metric though, some discretion is required… I find that this sort of tool is mostly useful to catch dumb mistakes.
DbUnit is a JUnit extension targeted at database-driven projects that, among other things, puts your database into a known state between test runs.
A nice recipe for unit testing Spring configured Hibernate.
