email article printer friendly

9 Tips for Automating Your Tests
Use these techniques to design, improve, and manage your test automation framework.
by Aditya Dada

August 23, 2005

When I took up the task of improving the test automation for Sun Java Systems Application Server, my job as the lead architect was making sure that the three thousand odd tests for a product comprising more than 10,000 classes were executed on three operating systems and three databases.

Since then, the framework I helped design has grown to support two platform architectures, five operating systems with their multiple versions, six databases, and five different teams. The tests are still executed every night, automatically, and all with a single command.

So whether you want to design a new test automation framework, improve your existing framework, or manage your test automation, here are some techniques to help.

1) Invest in a platform-independent build framework.
A few years ago we had a Makefile-driven framework. Shell scripts were also heavily used. We were spending time finding and removing white spaces from Makefiles, and defining functions separately for Windows and Unix in shell scripts. Then, Ant came along, and provided us a platform-independent way of doing things. Ant's XML format proved easy to understand and use. And because Ant is open source, selling it to everyone was easy.

But there's a downside to Ant as well. If you're creating one huge file with hundreds of lines of XML, and you miss closing a tag, then the file is rendered unusable—pretty much like what a white space does to a Makefile. So manage your XML files and keep them small and readable.

2) Follow the tree structure.
A natural way of managing the directories of tests is to follow the tree structure. That is, keep all common files and configuration files in a 'config' directory at the top. Keep libraries and utilities in a 'lib' and a 'util' directory under the root, respectively. Create all the component/module directories under the root. You can enhance this to first create the release/version directories and create the module directories under those.

The tree structure allows execution of a single branch, or the entire tree. So make sure that the test execution requirement in part drives the naming and ownership of the directories.

If your directory structure is running deep, it might prove useful to also implement a test driver in the form of a file containing a list of tests to be executed. This allows easy viewing of which tests have been executed, but might be a nightmare to maintain if it undergoes 20 changes a day by different people.