Automed User Inteface Testing

User interfaces components are hard to unit test with standard unit testing framework. There are several reasons for that. In my opinion the principal is the fact that user interface components rely heavily on the interaction between the user of the system and underlying framework of business(or other objects) supporting the user interface control. And sometimes, is quite hard to remove the component from its natural environment for testing purposes, as is the case with ASP.NET web components.
The solution to this problem is two fold. First all domain and infrastructure objects should be logically and physically removed from the user interface and unit tested separately using convectional testing methods. This is nothing new, there are numerous design philosophies associated with that (for example the MVC design pattern always so popular with web development frameworks). The second is to to test the user interface component attached to its underlying system base, in a separate - clean - environment specially prepared to for testing purposes using automated unit testing tools.
For example and ASP.NET application whose user interface is composed by a separate web component library and relies heavily on client side code to facilitate heavy user interactions with few page reloads in order to maximize user experience (ah, the oh so popular Microsoft buzz word of the moment) and to reduce stress load on the system. There are five distinct parts to this application:

• ASP.NET user interface


• ASP.NET web control


• ASP.NET web control domain objects (entities, repositories, services and specifications)


• Javascript user control attached objects


• Javascript domain object

All these parts compose the user interface of this theoretical (and so typical application). First , lets us remove all domain objects. Both client side and server side object can be tested using respective testing environments. Now for the remaining three elements there is no way of testing them separately. And, also there is no practical need. Because the goal of testing user interface components is not to see if each of them works correctly as a separate unit (it is impractical , because the amount of mocking requires a separate framework of its own - often custom made for one project only) , the goal it to test the user interface as one system (logical separated by functionality, just to give some order to the mess) in order to provide to the team and to the customer that the system which is built provides requested functionality.
This is accomplished by using automated unit testing frameworks. One that I especially like is Watin, an open source project under active development which allows any developer to programmatically test the user interface of any web application inside Firefox and Internet Explorer (which we are the two browser mostly tested by web developers).
Watin is a good framework. Of course there is place for improvement, by what is accomplished now is very useful in enterprise strength projects. For anyone who has developed with javascript using this framework will be easy and will come naturally.
I would recommend it for everyone doing serious web development in any environment and with any tools.