Test Case Design for Automated UI Tests


In this article, Chris McMahon offers an approach to implementing automated tests at the user interface level in a way that is visually simple and should save a lot of work when analyzing and maintaining tests down the road.

Almost everyone agrees that having automated tests at the user interface (UI) level is worthwhile, but analyzing and maintaining such tests can become very expensive very quickly if the tests are implemented poorly. As you grow your automated UI test suite, consider an approach like the one I'm about to describe. 

Consider your application as a circle, where all the application functions are inside the circle and the circumference of the circle provides an arbitrarily large number of access points to those functions. 

The Starting Points 
On your circle, draw a dot on the circumference. Now, draw another dot on the circumference a good distance away from the first. Now draw one on the circumference between the others. These represent starting places for your automated tests. As an example, let's say that the application you need to test will manage users, money, and time (since a lot of software does exactly that). 

If you are testing a Web application, each dot you draw on the circumference of your circle will be represented by a URL: 


The Destinations 
Inside your big circle draw three very little circles in arbitrary places. Label them "U," "M," and "T" in very small letters. Each of these little circles represents an end state of the application. 

Now, draw lines from the points on the circumference of the circle to the small circles inside. Each of these lines represents a path through the application. Your automated test will start at the outside of the circle and take a certain number of steps to arrive at a place within the circle. 

If the automated test traverses the path through the UI without any assertions failing, then the test will pass. 

Draw several more of these paths through the UI within your circle. Label them U1, U2, U3, M1, M2, M3, T1, T2, T3. You have a complex application; it will certainly take more than one test to validate that everything is working correctly. 

When you are done, your circle will be covered by a web of lines of various lengths and directions. Some lines will intersect. Some won't. Some areas might have greater density of lines than others. Hopefully, the circle will be more or less evenly covered by lines. 

This diagram of paths through the UI is a representation of a well-designed set of automated UI tests. It represents feature coverage, not code coverage. Also, the paths through the application are mostly orthogonal to each other. I'll talk about why this is important shortly, but first let's take a look at what can go wrong. 

StickyMinds is a TechWell community.

Through conferences, training, consulting, and online resources, TechWell helps you develop and deliver great software every day.