Chapter 8. Getting Feedback

Listing 8.2. Implementation of test time execution listener

public class ExampleTimeListenerTest {

@Rule

public TimeTestListener timeListener = new TimeTestListener();

@Test

public void tenMillis() throws InterruptedException { Thread.sleep(10);

}

@Test

public void twentyMillis() throws InterruptedException { Thread.sleep(20);

}

Instatination of the TimeTestListener object.

Our listener will be applied to both test methods.

If you run this test you would see output similar to the following:

twentyMillis: 21 tenMillis: 10

It would be cumbersome to repeat the same rule declaration in each and every test. Build tools allow you to specify which listeners should be used for all your tests. Appendix B, Running Unit Tests explains how to achieve this using Maven.

8.4. Readable Assertion Messages

An assertion message has just one purpose: to make the developer understand instantly what has gone wrong: no guessing, no head-scratching. You just look at the assertion message and you are sure about what it is that is not working. This does not mean that you know where the bug is, but it is the first step on the way to revealing and fixing it.

When looking at the examples in this book you may reach the conclusion that working on assertion messages is a waste of time. Well, yes, sometimes it is. However, bear in mind that you are now in "training mode". The examples are simple and you are focusing on them to the exclusion of all else. In real life it will be different. You will be surprised by a not-so- clear error message when you least expect it, when your mind is focused on some completely different part of the system (and also, probably, when the deadline is near…). Doesn’t it make more sense to lose 15 seconds now, and maybe save a lot of grey hairs later? It is up to you to decide.

Assertion messages provide feedback every time a test fails. Sometimes, in fact quite often, the default information printed by JUnit is good enough. In other cases you will have to do some additional work to make them really helpful. In general, you can do two things to improve the situation:

• add an additional message parameter to the assertXYZ() methods of JUnit (for example,

assertEquals("some message here", expected, actual);,

• override the toString() method of some domain objects.

183

Chapter 8. Getting Feedback

8.4.1. Add a Custom Assertion Message

From time to time, you may benefit from adding a custom message to the assertion method. For example (going back to the Money class that we discussed earlier), consider these two messages, each printed by a failing test. The first one is printed by the following assertion: assertEquals(10, money.getAmount()):

Listing 8.3. No assertion message

java.lang.AssertionError: Expected :10

Actual :15

The second output is printed by the following assertion: assertEquals("wrong amount of money", 10,

money.getAmount()):

Listing 8.4. Custom assertion message

java.lang.AssertionError: wrong amount of money expected: 10 but was: 15

While the first version (without any message) leaves us in doubt about the nature of the problem, the second version states explicitly that the problem was with money2. The gain is rather minimal: usually all you have to do is look at the test method name (which is always included in the stack trace) to understand the context.

In fact, the additional message is rarely required. Instead of working on that, you would be better off improving the name of the test method (see Section 9.2) so that when it fails, you know exactly why - just by reading its name.

8.4.2. Implement the toString() Method

A good example of when I would recommend doing some more work on an assertion message is the following: let us assume that there is a Client class and a test which creates two clients with different properties. If an assertion on clients’ equality fails (assertEquals(clientA, clientB)), we will encounter the following error message:

Listing 8.5. Cryptic assertion error message

java.lang.AssertionError:

Expected :com.practicalunittesting.Client@64ea66 Actual :com.practicalunittesting.Client@158f9d3

Hmm, not really much help, is it? In order to improve the message it is enough to override the toString() method of the Client class, e.g. like this:

Listing 8.6. Implementation of the toString() method

@Override

public String toString() { return "Client{" +

"name='" + name + '\'}';

}

2You could call this a ‘real-life example’, couldn’t you? ;)

184