A Real-Life Example


Testability begins with the layout of your data storage. Lisa's team worked on a Web application initially developed by another organization. It had a complex data model already in place, with each content type being maintained having its own set of tables, for a total of over 50 tables. There was no time to change the schema. The resulting object model had 49 classes.

The same operations on different items in the database needed completely different classes and thus completely different tests. Each test was unique code from start to finish. A SubmitRequest for content item A would not work for submitting a request for content item B. Very little code could be shared between test scripts.

The team was next asked to develop a similar application for a different Web site but was allowed to design the database schema. They were able to make this application much more generic, using only four tables. The object model needed only nine classes. Now the SubmitRequest test script worked for every type of content. This made test script development go much faster, and the scripts were vastly easier to maintain.

Rethinking the design for all the content management, the team came up with a design needing just two tables, where a single definition of content could be used to represent all types of information. This generic design meant that the test scripts could take advantage of a library of generic test modules: one for editing, one for submitting a request, one for canceling a change, and so on.

Figure 28.1 shows the design for all three projects. The third design was not only easier to test it was, of course, much easier to write, and code maintenance was also much easier.

Figure 28.1. The three designs

graphics/28fig01.gif

Another good example of designing an application for maximum ease of testing is the project described in "One Team's Experience with Direct-Call Test Automation" in Chapter 23. When programmers have worked alongside testers and learned the value of acceptance tests and the importance of automating them, they think about acceptance testing up front. They're especially good about doing this when they've suffered the pain of having to automate tests for an application that's test-unfriendly.

If you don't have the luxury of developing a system from the ground up, encourage your team to refactor as much as possible to facilitate test automation. Build time for this into your story estimates. It'll pay off quickly when you spend much less time creating and maintaining automated tests. If your team consistently spends 30% or more of development time doing test automation tasks, see what you can do to improve testability.



Testing Extreme Programming
Testing Extreme Programming
ISBN: 0321113551
EAN: 2147483647
Year: 2005
Pages: 238

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net