« March 2005 | Main | April 2006 »
June 03, 2005
Abstractions in Test Code
In object-oriented programming (OOP) people are familiar with abstracting things and layering so that the system stays resilient to changes. The classic example is the MVC (Model-View-Controller) architecture that allows
the user interface (View) to change without having to change the underlying business logic (Model). Concepts like this are drastically missing from test code. I propose the following types of abstractions applied to test code and in particular, acceptance test code (aka GUI tests, functional tests):
1. Abstract the navigation logic of your application.
There's no need for test cases to know the details of how to navigate around the application. All this does is tightly couple the navigation logic to each test so if the navigation logic changes there could be hundreds of tests to update to use the new navigation. The Transporter pattern deals with this issue.
2. Abstract the test steps
Tests shouldn't have to specify all the test steps explicitly. That makes them tightly coupled to that sequence of test steps, so if a step has to be added or removed that would involve a significant maintenance cost. One solution is to abstract the test steps out to a Template class and make each test implement just a few template methods.
3. Abstract the test data
This is a huge topic that I'm not going to cover thoroughly here. Test data and the management of test data is an acquired skill. Too often, test tools focus on driving the GUI and test data management is an afterthought. And don't tell me that the tool can import your test data from an Excel or CSV file. It's not that simple. What about the scenarios where your tests need the application to be in a certain state before they're run? That would involve direct database access that most test tools lack.
There is also the issue of test data generation. Most tools make you manually specify the test data to use. This is not very automated and leads to a tight coupling between database schema and tests. Instead, there should be a test data layer that will supply tests with data they need. That way tests don't have to hard code data.
4. Abstract the visual details of a page
Tests shouldn't have to know the names of specific widgets on a page they are interacting with. Otherwise, they become tightly coupled to the visual representation of the application and sensitive to any changes in the application. The Domain Test Object (DTO) pattern addresses this problem by modeling the page as an object.
Posted by Misha Rybalov at 05:48 PM | Comments (0)