DESIGN FOR REUSE

.................................................................................................................Main Page / Back to Design Patterns / Back to Test Automation Patterns

Pattern summary

Design reusable testware.

Category

Design

Context

Use this pattern for long lasting and maintainable automation. It isn't necessary for disposable scripts.

Description

Design modular scripts: write script code for some functionality in only one place and call it when needed. In this way you can reuse the components again and again and if you do need to change something you have to implement and test it only in one place.
Reuse test data as much as possible.

Implementation

• When you see that you need to use again a part of some script (keyword), extract it and build with it a new script (keyword) that you can then call from the original script and from any future scripts (keywords) that may need it. Be sure to document exactly what it does and what parameters must be passed and give it a name that makes it easy to find.
• SINGLE PAGE SCRIPTS: write a script for every screen you want to automate, where you include all the GUI-objects on the screen. The input parameters can be used to communicate which GUI-objects will be activated in the specific test case and how they will be activated. For example if a parameter is missing, the respective GUI-object will be ignored.
• Implement an OBJECT MAP: if the objects get meaningful names it will be easier for the testers to understand the scripts. Also in this way you pave the way for your scripts to achieve TOOL INDEPENDENCE.
• Write a script for all the various set-ups that you will need. Again define with input parameters the specifics for each test case.
• Generate test data that can be reused repeatedly (for instance a customer record with some specific characteristics)
• DOCUMENT THE TESTWARE: give the “building blocks” (scripts or data) descriptive names so that a tester can see at a glance what is available, how to use it and when to use it.
  

Recommendations
If possible get a developer to coach you in GOOD PROGRAMMING PRACTICES.

Issues addressed by this pattern

GIANT SCRIPTS
HIGH ROI EXPECTATIONS
INADEQUATE DOCUMENTATION
INCONSISTENT DATA
LOCALISED REGIMES
OBSCURE TESTS
TEST DATA LOSS
HARD-TO-AUTOMATE RESULTS

Experiences

If you have used this pattern, please add your name and a brief story of how you used this pattern: your context, what you did, and how well it worked - or how it didn't work!

.................................................................................................................Main Page / Back to Design Patterns / Back to Test Automation Patterns