How to reduce code duplication

In a previous blog entry I talked about starting and ending test cases in the same place. One of the problems with this is that there will be duplication in test cases. For example, I might have the following two test cases:

Test#1
- Log into web site
- Find a product to purchase
- Add to shopping cart

Test#2
- Log into web site
- Find a product to purchase
- Add to shopping cart
- Check out

If the way you log in, find a product or add to shopping cart changes there will be two locations to update. If 99% of the test cases require you to log in, there could be hundreds if not thousands of instances. A change in the log in process could take days to update.

The solution is to create libraries. You can organize them by feature or by page. I typically organize them by page. You could write detail libraries that do atomic actions (click button, fill in form, go to page, etc.) and other libraries which do higher level actions. The higher level actions could be calls to a set of the atomic actions.

Your test case would then be much shorter and simpler to write. As you build up the library of actions, writing test cases will be faster and faster. In other words, the time spend up front will save you time in the long run.

The key to doing this well is organization. You need to look at how other, successful, libraries are organized and try to make your libraries reflect the same consistent structure. Use descriptive names. Both for the grouping (classes in Java, modules in Perl, etc.) and for the method calls.

A test case should almost read like your native tongue and the high level methods should read almost like your native tongue as well. The atomic methods should be simple and straight forward.

Finally, all atomic methods should make sure the input parameters are valid (fail if they are not with a good error message), the state of the web page is what you expected (again fail if it is not) and you get the results you expect at the end of the method. That is, from Computer Science 101, make sure the pre and post conditions are met!

A good error message does not assume what went wrong. Instead it will tell you the state of the test case and let a human determine what was wrong.