DESIGN FOR REUSE
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.
Potential problems
If your developers don't implement GOOD PROGRAMMING PRACTICES then try to learn from books, conferences etc.
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 and would like to contribute your experience to the wiki, please go to Feedback to submit your experience or comment.
.................................................................................................................Main Page / Back to Design Patterns / Back to Test Automation Patterns