如何设置Zk会话（org.zkoss.zk.ui），以便可以对扩展GenericForwardComposer的控制器类进行单元测试

Question

I'm trying to unit test an existing ZK controller and I want to find a way to handle a call like the following while unit testing my Controller,

Sessions.getCurrent().setAttribute("from", from.getValue());

I'd be happy to either replacing the offending code, or find a way around it for the unit test. My goal is testability by dealing with the NullPointerException

My test is simple (it's not too bad a place to start...)

    @Test
    public void zkControllerDoesMockingInitialisedSuccessfully() throws Exception {

    T2TripBigDaoInterface tripBigDao = createMock(T2TripBigDao.class);
    ZkFieldValidator fieldValidator = createMock(ZkTextFieldValidator.class);
    FieldRangeValidator rangeValidator = createMock(DefaultFieldRangeValidator.class);

    TripController controller = new TripController(tripBigDao, fieldValidator, rangeValidator);


    replay(tripBigDao, fieldValidator, rangeValidator);

    controller.onClick$getTrips(new Event("getTrips"));

    verify(tripBigDao, fieldValidator, rangeValidator);

    // Test purpose: Just get a unit test of the controller running to start with....
}

---

Extract of the controller:

 public class TripController extends GenericForwardComposer { .... public void onClick$getTrips(Event event) throws Exception { Sessions.getCurrent().setAttribute("from", from.getValue()); Sessions.getCurrent().setAttribute("to", to.getValue()); .... } .... 

---

Extract of the stack trace:

 java.lang.NullPointerException at com.t2.webservice.controller.alert.TripController.onClick$getTrips(TripController.java:72) at com.t2.webservice.controller.alert.TripControllerTest.zkControllerDoesMockingInitialisedSuccessfully(TripControllerTest.java:45) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) 

Answer 1

This is one of the things I dislike most about ZK: their use of singletons and the impact that has on testability.

What I end up doing is removing any references to their singletons ( Sessions , Executions , Selectors ) from my controllers. In normal operation these singletons get used, but in tests they can be mocked out.

How you go about this is up to you, I still haven't found a pattern I'm in love with.
Here's one idea..

public class TripController extends GenericForwardComposer {

    private final TripSessionManager tripSessionManager;

    public TripController() {
        // ZK calls the default constructor
        this(new ZKTripSessionManager());
    }

    protected TripController(TripSessionManager tripSessionManager) {
        this.tripSessionManager = tripSessionManager;
    }

    public void onClick$getTrips(Event event) throws Exception {
        tripSessionManager.setTo(to.getValue());
        tripSessionManager.setFrom(from.getValue());
    }

}

Your TripSessionManager would then look like this..

public interface TripSessionManager {

    void setTo(String to);

    void setFrom(String from);

}

With the default ZK implementation relying on the Sessions singleton..

public ZKTripSessionManager implements TripSessionManager {

    public void setTo(String to) {
        setAttribute("to", to);
    }

    public void setFrom(String from) {
        setAttribute("from", from);
    }

    private void setAttribute(String name, String value) {
        // only valid if called in a ZK managed thread
        Sessions.getCurrent().setAttribute(name, value);
    }

}

By abstracting out the implementation, you can test your controller with a mock TripSessionManager ..

@Test
public void test() {
    TripSessionManager mockTripSessionManager = mock(TripSessionManager);
    when(mockTripSessionManager.setTo(anyString()).thenAnswer(...);
    when(mockTripSessionManager.setFrom(anyString()).thenAnswer(...);
    TripController controller = new TripController(mockTripSessionManager);
}

You could also imagine different ways of managing these new dependencies (eg: avoid new ZKTripSessionManager() ) using dependency injection frameworks like Spring or Guice.