-
-
Save jmaicher/4257510 to your computer and use it in GitHub Desktop.
public class Unit { | |
public Unit(EventDispatcher dispatcher) { | |
dispatcher.addHandler(MyEvent.class, new IEventHandler() { | |
public void onEvent(MyEvent event) { | |
// some behavior | |
} | |
}); | |
} | |
} |
public class UnitTest { | |
@Test | |
public void whenDispatcherTriggersMyEventThenIExpectBehaviour() { | |
EventDispatcher mockedDispatcher = mock(EventDispatcher.class); | |
new Unit(mockedDispatcher); | |
ArgumentCaptor<IEventHandler> myEventHandlerCaptor = ArgumentCaptor.forClass(IEventHandler.class); | |
verify(mockedDispatcher).addHandler(eq(MyEvent.class), myEventHandlerCaptor.capture()); | |
IEventHandler myEventHandler = myEventHandlerCaptor.getValue(); | |
MyEvent mockedEvent = mock(MyEvent.class); | |
myEventHandler.onEvent(mockedEvent); | |
// verify behavior | |
} | |
} |
Thanks for your response, I appreciate it!
It's a unit test and should test how the unit behaves when the dispatcher dependency triggers an event.
My intuition was telling me the same thing. There is too much going on for one test, so it's probably a design flaw.
Let me give my example a little bit more context:
public class ConnectionManager {
private HashMap<Connection> connections;
public ConnectionManager(Server server) {
this.connections = new HashMap<Connection>();
server.addHandler(ConnectionEvent.class, new IEventHandler() {
public void onEvent(Event event) {
ConnectionManager.this.addConnection( (ConnectionEvent event).connection );
}
});
}
public void addConnection(Connection conn) {
this.connections.put(conn);
}
}
What your are suggesting is to outsource the anonymous inner class and rather inject it as dependency.
This means the behavior I want to test is not part of the unit anymore and can be tested separately.
package connection_manager;
class ServerConnectionEventHandler implements IEventHandler {
private ConnectionManager connectionManager;
public ServerConnectionEventHandler(ConnectionManager connectionManager) {
this.connectionManager = connectionManager;
}
public void onEvent(Event event) {
// assume we know it's save
this.connectionManager.add( (ConnectionEvent event).connection );
}
}
Okay, that works. For the sake of good design I would actually put up with the implied overhead.
I mean, coming up with names for these classes will probably take some time :-)
- Java syntax?
- What is the responsibility of
ConnectionManager
? Whenever aConnectionEvent
gets issued by thisServer
instance, theConnectionManager
instance tracks the events connection? To me it is unclear, why theConnectionManager
is configuring theServer
at all. Maybe it should be calledServerConfigurator
. About Managers: http://c2.com/cgi/wiki?DontNameClassesObjectManagerHandlerOrData - Java package names go like:
org.jmaicher.connection;
. You don't want to have asrc/main/java/connection_manager
directory, do you? - Interface names in Java are usually not prefixed with the letter "I". This is .net-Style.
Let's put 1, 3 and 4 aside, they doesn't matter at all right now.
I made up this example and quickly wrote it in the textarea to show some concrete testworthy behavior. Let's exchange ConnectionManager
with ServerMonitor
and say it needs to display current connections to the user. The pattern doesn't change.
Its all about naming things ;-) #ServerObserver
@jmaicher
thanks man,this one helped me ..
Rich Hickey: "Your mock object is a joke; that object is mocking you. For needing it."
There is a lot of mocking involved here that is hard to understand and maintain. I would try to avoid mocking whenever possible. What are you actually testing? The Unit? The Dispatcher? Or the behavior? At least from your comment, you're checking the behavior. So, for the sake of good design, this behavior should (IMHO) be injectable.