[4.2.0-489] Unit testing controllers - specifically event handlers

[twasink]

One of the promoted advantages of 4.2.0, as per the announcement post, is that controllers can be unit tested.

I have certainly found that I can easily instantiate a controller and unit test the methods without problems. However, I'm at a loss as to how to unit test the event listeners.

Given a controller and Jasmine unit test like this:

Ext.define("TestApp.controller.TestController", {
    extend : 'Ext.app.Controller',


    init : function() {
        this.control({
            'button' : { click : this.onClick }
        });
    },


    onClick : function(btn, e, eOpts) {
        console.log("Button was clicked");
    }
})


describe("Test Controller", function() {
    it("should be able to be created", function() {
        var test = Ext.create('TestApp.controller.TestController');
        
        spyOn(test, 'onClick');
        
        test.init();
        
        // Do something _here_ to simulate a button clikc
        
        expect(test.onClick).toHaveBeenCalled();
    });
});

what would be the best thing to do to trigger the event handler? Short of instantiating a view class that matches the selector (which would normally be more complex, of course)

[mitchellsimoens]

The EventBus is not put onto the controllers themselves instead of getting them from the application. Before the controller would have to go to the application to set the listeners but now the bus is put on each controller.

[nohuhu]

Controller testing isn't easy because of the number of components involved. If you consider how Controllers work, there are two major things to test: component selectors/ref selectors and controller methods. The latter can be tested in the usual way, whereas component selectors depend on Ext.ComponentQuery, which in turn depends on actual components being instantiated for queries to be meaningful.

Starting from this point, I'd suggest breaking Controller tests into two suites: first would instantiate the relevant View(s) and run over component selectors to test that they actually return Views in question; the second would test everything else. If your views are too heavy to be instantiated for testing, you can use mockups that replicate the structure of your view without adhering to the same layout constraints.

If and when you find yourself with a View that's too big to be tested this way, that would mean it's a good candidate for refactoring.

Just my 2¢ anyway.

Regards,
Alex.