◆ Problem
You want to test an event listener.
◆ Background
The power of the Observer (or Event Listener) is that it is not coupled to the Observable (or Event Source). The nature of their collaboration makes it possible to test the Observer in perfect isolation, although on the surface it seems strange to use the Observer without the Observable. When considering how to test an Observer, the first idea that might come to one’s mind is to create a fake Observ- able—an object that plays the role of the real Observable, but does something simpler. It turns out that testing an Observer is even easier than that.
◆ Recipe
The simplest way to test an Observer is simply to invoke its event handler methods directly and make assertions about what they do. There is no need to create a fake Observable: the test case class itself is good enough.3 You can take advantage of the fact that the Observer does not care about the origin of the events it is listen- ing for, by merely invoking the event handler method directly with a variety of events. You can easily simulate any condition you like in this way.
We look to JUnit itself for an example. One of its core interfaces is junit.frame- work.TestListener. A test listener registers with the test runner to find out when tests begin, when they end, and when they fail. The text-based test runner registers a TestListener to print out a dot (.) for each test, an “F” for each failure and an “E”
for each error. Although JUnit has already implemented junit.textui.Result- Printer, in this example we will build our own implementation.
Because event handler methods typically do not return values, we need to observe some side effect to verify their correctness. In this case, the side effect is
3 This approach is not quite the Self-Shunt Pattern, although it is similar in spirit. Sometimes we want to add labels to things to make them sound important, but not here—we’re simply invoking methods, just as we did way back in chapter 2.
546 CHAPTER 14
Testing design patterns
whatever the test listener prints out...somewhere. In production, this test listener should print to the console, but that would be an invisible side effect for the tests.
Referring to the techniques in recipe 2.2, “Test a method that returns nothing,”
we make the side effect visible by providing the TextBasedTestListener a Print- Writer to which to print. In our tests, we use a PrintWriter that wraps a String- Writer, so we can retrieve the output as a String, while in production we use a PrintWriter that redirects to System.out, the console. Look at the tests in listing 14.1, the first few of which invoke each event handler method in isolation to verify its basic behavior.
package junit.cookbook.patterns.test;
import java.io.*;
import junit.cookbook.patterns.TextBasedTestListener;
import junit.framework.*;
public class TextBasedTestListenerTest extends TestCase { private TextBasedTestListener testListener;
private StringWriter stringWriter;
protected void setUp() throws Exception { stringWriter = new StringWriter();
testListener =
new TextBasedTestListener(new PrintWriter(stringWriter));
}
public void testStartTestEvent() throws Exception { testListener.startTest(this);
assertEquals(".", stringWriter.toString());
}
public void testAddFailureEvent() throws Exception {
testListener.addFailure(this, new AssertionFailedError());
assertEquals("F", stringWriter.toString());
}
public void testAddErrorEvent() throws Exception { testListener.addError(this, new RuntimeException());
assertEquals("E", stringWriter.toString());
}
public void testEndTestEvent() throws Exception { testListener.endTest(this);
assertEquals("", stringWriter.toString());
} }
Listing 14.1 Tests for a text-based TestListener implementation
547 Test an Observer (Event Listener)
These tests are straightforward: at the start of a test, we ought to see a dot; when a test fails, we ought to see an “F”, and so on. We write the production code to make these tests pass.4 Now we know that our TextBasedTestListener correctly handles the various events occurring on their own. There are no special case variations on these events that we can think of, but do we need any other tests? Just to be sure, in list- ing 14.2, we try out the various “end-to-end” scenarios that occur when executing a test.
package junit.cookbook.patterns.test;
import java.io.*;
import junit.cookbook.patterns.TextBasedTestListener;
import junit.framework.*;
public class TextBasedTestListenerTest extends TestCase { private TextBasedTestListener testListener;
private StringWriter stringWriter;
protected void setUp() throws Exception { stringWriter = new StringWriter();
testListener =
new TextBasedTestListener(new PrintWriter(stringWriter));
}
// Basic event handler tests omitted
public void testCompletePassingTestScenario() throws Exception { testListener.startTest(this);
testListener.endTest(this);
assertEquals(".", stringWriter.toString());
}
public void testCompleteTestFailureScenario() throws Exception { testListener.startTest(this);
testListener.addFailure(this, new AssertionFailedError());
testListener.endTest(this);
assertEquals(".F", stringWriter.toString());
}
public void testCompleteTestErrorScenario() throws Exception { testListener.startTest(this);
testListener.addError(this, new RuntimeException());
testListener.endTest(this);
assertEquals(".E", stringWriter.toString());
} }
4 For this recipe we have decided to work in Test-Driven Development mode. If you do not like TDD, then pretend we wrote the code first—whichever you prefer.
Listing 14.2 Further text-based TestListener tests
548 CHAPTER 14
Testing design patterns
These tests verify that TextBasedTestListener handles the typical event flows the way we would expect. The last feature we need to add makes it easier to eyeball how many tests have executed: insert a line break every forty tests so that as we see a row of dots we know that forty tests have executed. Here is that test.
public void testAddLineBreakAfterFortyTests() throws Exception { for (int i = 0; i < 41; i++) {
testListener.startTest(this);
}
assertEquals(
"...\r\n.", stringWriter.toString());
}
Count them if you like: there are forty dots, a line break, and then one more dot.
If we had to generate more long lines of dots, we would extract a method like StringUtil.repeat() to do it; but until then, we’ll live with the duplication, or lack of abstraction, however you prefer to see it. This is the test that forces the TextBasedTestListener to keep a count of the number of tests and invoke println() at the right time. We did not need any test runner, real or fake, to gen- erate the events for these tests. Instead, we simply invoke the event handler meth- ods with some sample events and verify the way the methods respond.
◆ Discussion
The event-handling logic for TextBasedTestListener was very simple: print some characters to a PrintWriter. Some event-handling logic is complex enough to present its own testing challenges, making it difficult to use as the “observable side effect” to test the event handlers. Observer tests should be very simple, and if they are not, then that is generally a sign that the Observer is “working too hard.” It might be violating the Single Responsibility Principle. For example, consider an event handler that sends a JMS message when it receives an event notification.
Verifying that the event handler sent the appropriate JMS message involves JMS servers, message marshalling and unmarshalling, and on and on—quite a com- plex test environment for something that ought to be much simpler. Instead, we recommend separating the event handler’s key responsibilities, which are proba- bly:
■ Determine the message content and destination, depending on the event received.
■ Marshal the content into a JMS message and send it to its destination.
549 Test an Observer (Event Listener)
Extract the second responsibility and move it into a separate class and introduce an interface containing a method that takes the message content and destination as a parameter. Name the new interface MessageSender.5 Your event handler now creates the message content, determines the destination, and invokes its MessageSender. This is a much simpler side effect to observe during testing: you can use a mock objects approach to verify that your event handler invokes MessageSender correctly.
Listing 14.3 shows an example that uses EasyMock to verify this method invocation.
package junit.cookbook.patterns.test;
import junit.cookbook.patterns.*;
import junit.framework.TestCase;
import org.easymock.MockControl;
public class MessageSendingObserverTest extends TestCase { private MessageSendingObserver observer;
private MessageSender messageSender;
private MockControl messageSenderControl;
protected void setUp() throws Exception { messageSenderControl =
MockControl.createControl(MessageSender.class);
messageSender = (MessageSender) messageSenderControl.getMock();
observer = new MessageSendingObserver(messageSender);
}
public void testAbcEvent() throws Exception { messageSender.sendMessage(
"ABC-related content", "ABC destination");
messageSenderControl.replay();
observer.handle(new AbcEvent());
messageSenderControl.verify();
} }
We have highlighted in bold print the two main parts of the test. The first is recording the method invocation you expect: that someone will invoke sendMes- sage() with the correct message content and destination. The second is simulat- ing the event by invoking the event handler directly. This verifies that when the
5 Not a great name, we know, but you will think of something better later.
Listing 14.3 Testing MessageSender with EasyMock
550 CHAPTER 14
Testing design patterns
MessageSendingObserver receives an AbcEvent, it asks the MessageSender to send the right message. Now no matter how many different events might result in send- ing a message, you only need one small set of tests for the JMS-based Message- Sender implementation you use in production. (We discuss testing JMS message producers in recipe 11.12, “Test a JMS message producer.”) By separating the event handler’s two main responsibilities, we can ignore the complexity of send- ing a real JMS message when all we need to verify is how our Observer determines the content and destination of a message based on the event it receives. The resulting tests are simpler and faster, and the resulting design is more flexible.
◆ Related
■ 2.2—Test a method that returns nothing
■ 11.12—Test a JMS message producer