Automated testing is a key part of agile development. If you are changing software in frequent small increments, you need to be sure that your new changes have not broken the existing code. Because the increments are usually between one and four weeks long, there is no time for test regimens that take weeks to complete. And manual tests become especially tedious (which leads to errors and oversights) if they have to be repeated frequently.
GUIs are frequently considered something difficult to test in an automated fashion. One thing that can help a lot is separating the production of data from the presentation of data, using the Model-View-Controller, Model-View-Presenter, or Model-View-ViewModel design patterns. (Here is a good overview of the differences between MVC, MVP, and MVVM.) In all three of these design patterns, the Model is the part of the system that contains its state and performs all calculations.
You can write automated unit test programs that call methods in the Model and check for expected results, just as with any module, without worrying about how it is presented on the screen. Testing the GUI itself is just a matter of making sure that when you click on a button, it sends the right signal to the ViewModel, and when you pass the View Model a particular value, it is properly displayed. Even if you have to do these tests manually, it is easy to write a test driver that tells you when each button has been clicked, and populates each display with dummy data. This is a lot easier than trying to figure out what you have to do to the system to make it display a particular thing.
There are some other benefits to separating the production and presentation of data. It can make it a lot easier to change the GUI without fear of messing up the data production. For example, Boonex Dolphin, a content-management system for social websites, does not directly generate its HTML web pages. Instead, it generates XML, which is run through an XML stylesheet (XSLT) to format it into a web page. This lets the web page designer concentrate on the design, without having to worry about the business logic. It also makes it easy to have several themes available, completely changing the look of the website, by just changing the XML stylesheets, without changing the business logic of the website.
Another example is XAML (Extensible Application Markup Language), an XML-based markup language for designing GUIs. It is used by Microsoft's Windows Presentation Framework and Silverlight application-development frameworks, as well as NoesisGUI, a platform-independent GUI middleware package that is available for Windows, OSX, and Linux, as well as several popular game and rendering engines.
A designer can design a GUI either visually, using Microsoft Blend or Microsoft Visual Studio, or by hand with a smart XAML editor like Kaxml that immediately displays how the XAML will be rendered. The designer can concentrate on what the page looks like, without having to get involved with how the data is calculated.
This allows separation of duties: someone who is good at design can design the GUI, and someone who is good at code and business logic can code the Model and ViewModel. Even if you are a one-person indie shop, and have to wear several hats, it is easier to be in a design headspace or a coding headspace, and not be constantly switching back and forth between the two.
Yet another benefit is code reuse. If your business logic is not tied to the GUI, it makes it a lot easier to reuse it in a different application.
Designing your GUI for automated testing helps you meet your sprint commitments, makes changing it easier, and makes your code more reusable.
What's not to like about that?
