Unittesting GUI. MVC model. When to move data to controller

Question

I've been reading different opinions about how to unittest GUI in Java and it is clear that the best approach is to design the code in a MVC model, in order to be able to test everything. Anyway I would like to ask for your opinion on a more concrete problem:

I have a GUI in Java. A button has a selection listener that executes some code

button.addSelectionListener(new SelectionAdapter() {
    public void widgetSelected(SelectionEvent event) {
        //code        
    }
})

My solution for this implementation would be as follows: I place the //code in a method of an external class that will be the "controller" of my model. This method has to be public if I want to call it and that will allow me to test it.

Everything looks pretty easy but I have a couple of questions:

1. What if the //code is just doing something for the class (viewer) itself? In that case it makes no sense to extract this code to other class or it will indicate that my code smells. Furthermore if the method remains in the viewer it will be private so I'll have no way to test it

2. What if the //code is getting access to attributes or widgets or whatever within the viewer? In such a case it would make no sense to place the code into another class just for testing reasons due to the fact that this attributes will need to be passed as parameters to this other class and that will make both classes to depend upon eachother

3. If I still move the //code to the new class: should I test the behaviour of the button? In Java it is possible to simulate a click on the button. Doing that I would be able to test whether the button is really doing what it is meant to do or not. Is it worth it or should I do it with functional testing?

Answer 1

What if the //code is just doing something for the class (viewer) itself? In that case it makes no sense to extract this code to other class or it will indicate that my code smells. Furthermore if the method remains in the viewer it will be private so I'll have no way to test it

In general, I prefer not to subclass GUI widgets (see below for my reasons). So I would likely put the selection listener in a separate class.

What if the //code is getting access to attributes or widgets or whatever within the viewer? In such a case it would make no sense to place the code into another class just for testing reasons due to the fact that this attributes will need to be passed as parameters to this other class and that will make both classes to depend upon eachother

I try not to hand GUI widgets around. Instead, I create interfaces that represent the information or the actions, and hand those around. Of course each concrete implementation of those interfaces might know about a GUI widget (preferably a single GUI widget), but none of my other code has to know about widgets.

This means I can test my code in terms of those interfaces. And each concrete implementation does as little as possible in its interactions with the GUI widgets. Their job is either to respond to a user gesture by calling a single method on a single object (via an interface), or to respond to a model or controller update by telling some widget what to display.

Of course, it isn't always that easy. But I can generally write GUI-related code that way, and it's very testable. I find the "extra" layer of adapters and delegates worth it.

If I still move the //code to the new class: should I test the behaviour of the button? In Java it is possible to simulate a click on the button. Doing that I would be able to test whether the button is really doing what it is meant to do or not. Is it worth it or should I do it with functional testing?

Mostly I trust that the GUI framework will do its job (assuming I understand its job, which is sometimes a bad assumption).

This is the main reason I try not to subclass GUI widgets. If I can trust the framework to do its job, and I haven't added any code by subclassing, there's little need to test the widgets. Instead I test my delegates and adapters, which are isolatable and testable.

Of course, I still have to write tests to ensure that I'm wiring things up correctly.