In a previous blog I described test driven development (or TDD) and hinted that it has many advantages. However, when it comes to graphical user interface (UI) development, programmers expect less benefit from this development technique. The expected benefit outweighs the potential gain and many give the method no more thought. This is concerning because without test-driven development, the value of continuous integration and ultimately the benefit of the Agile method remains unattainable for the team.
The trouble stems from the fact that the user interface consists of widgets - the forms, buttons, drop-down boxes and so on. These widgets display information to the user and provides him with ways to interact with the application. In order to test this interface, someone that understands the expected behaviour use the widgets verify that the behaviour meets his expectation. This is a difficult and sometimes subjective assessment. Also, the UI test can only be written after the widgets has been implemented; and even then the cost of writing such tests might be too high.
Does this mean TDD must forever be discarded by UI developers everywhere? Of course not. In fact UI developers should embrace the method with more vigour than server side developers. User interfaces are the visible parts of the application and a change anywhere has a real chance of ending up on the user interface somewhere. In other words: it is a high maintenance area of the application. As such it should be covered with unit tests and refactored often.
The well trodden road to improve the maintainability of an application is to make sure you have a set of maintainable modules. Each module is a cohesive unit and it is loosely coupled with the other modules. The trick is to keep the user interface modules lean and avoid coupling between these UI modules.
Consider the one module application that is built entirely with forms. All the persistence, the validation rules, the processes are written in classes that extend the basic form class. This idea was promoted by the older data binding technologies. Only the simplest applications should be built this way. And even simple apllications suffer when new requirements imposes radical changes. Test driven development will not be a first choice for a developer that chooses this 'one module' application architecture.
Lets look at another plan: a two module application. The one module runs on the server, and the other module is the user interface. At least for the lucky winner of the server side development, test driven development is practical, he can start playing right away. But the user interface developer sits with the problem of validation rules, caching, some process issues and other not so little matters. He must now also retrofit his 'wacky' user interaction ideas on the 'logical' sever side API. You guessed it, no test driven development on the user interface side yet.
The answer is obviously to have more than two modules. Consider carefully what is meant by the term 'user interface', and divide the identified concerns into a number of modules. While doing this keep the size of the modules that involve widgets to a minimum. Apart from these 'widget modules' all the development work can now follow the test-driven method. The way to end up with these modules is to design them into the architecture from the start and then evolve them as the application grows.
To migrate to this Utopia, you'll need to make two hard choices:
* This first choice is to rid yourself from the data-table-driven world and move into the domain-driven way of application development. At least you'll end up with one more module: the domain module. There are many established patterns you can choose from; and test driven development is ideal for domain modules.
* The next hard choice is to choose a good user interface architecture. In many cases your development environment would lean towards a specific flavour. If it leans toward the bad old flat databinding model; it is time to look around for better tools. Patterns from the model-view-controller and model-view-presenter worlds are well established alternatives. It is important to know the limitations of the particular UI architecture and to understand how to use it well.
Generally there are always ways to isolate the model aspects, the view aspects and the control aspects of the application. The widgets are in the views; and apart from the view modules TDD works for everything else.
Keep that chin up, even for graphical user interface development test driven design is within the realms of possibility!
The trouble stems from the fact that the user interface consists of widgets - the forms, buttons, drop-down boxes and so on. These widgets display information to the user and provides him with ways to interact with the application. In order to test this interface, someone that understands the expected behaviour use the widgets verify that the behaviour meets his expectation. This is a difficult and sometimes subjective assessment. Also, the UI test can only be written after the widgets has been implemented; and even then the cost of writing such tests might be too high.
Does this mean TDD must forever be discarded by UI developers everywhere? Of course not. In fact UI developers should embrace the method with more vigour than server side developers. User interfaces are the visible parts of the application and a change anywhere has a real chance of ending up on the user interface somewhere. In other words: it is a high maintenance area of the application. As such it should be covered with unit tests and refactored often.
The well trodden road to improve the maintainability of an application is to make sure you have a set of maintainable modules. Each module is a cohesive unit and it is loosely coupled with the other modules. The trick is to keep the user interface modules lean and avoid coupling between these UI modules.
Consider the one module application that is built entirely with forms. All the persistence, the validation rules, the processes are written in classes that extend the basic form class. This idea was promoted by the older data binding technologies. Only the simplest applications should be built this way. And even simple apllications suffer when new requirements imposes radical changes. Test driven development will not be a first choice for a developer that chooses this 'one module' application architecture.
Lets look at another plan: a two module application. The one module runs on the server, and the other module is the user interface. At least for the lucky winner of the server side development, test driven development is practical, he can start playing right away. But the user interface developer sits with the problem of validation rules, caching, some process issues and other not so little matters. He must now also retrofit his 'wacky' user interaction ideas on the 'logical' sever side API. You guessed it, no test driven development on the user interface side yet.
The answer is obviously to have more than two modules. Consider carefully what is meant by the term 'user interface', and divide the identified concerns into a number of modules. While doing this keep the size of the modules that involve widgets to a minimum. Apart from these 'widget modules' all the development work can now follow the test-driven method. The way to end up with these modules is to design them into the architecture from the start and then evolve them as the application grows.
To migrate to this Utopia, you'll need to make two hard choices:
* This first choice is to rid yourself from the data-table-driven world and move into the domain-driven way of application development. At least you'll end up with one more module: the domain module. There are many established patterns you can choose from; and test driven development is ideal for domain modules.
* The next hard choice is to choose a good user interface architecture. In many cases your development environment would lean towards a specific flavour. If it leans toward the bad old flat databinding model; it is time to look around for better tools. Patterns from the model-view-controller and model-view-presenter worlds are well established alternatives. It is important to know the limitations of the particular UI architecture and to understand how to use it well.
Generally there are always ways to isolate the model aspects, the view aspects and the control aspects of the application. The widgets are in the views; and apart from the view modules TDD works for everything else.
Keep that chin up, even for graphical user interface development test driven design is within the realms of possibility!
Posts
0 comments:
Post a Comment