TOOL DEPENDENCY

From Test Automation Patterns
Revision as of 08:47, 4 May 2018 by Seretta (talk | contribs) (Put topic titles in capital letters)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search
.................................................................................................................Main Page / Back to Design Issues / Back to Test Automation Issues

Issue summary

Test automation is strongly dependent on some special tool.

Category

Design

Examples

  1. You have written all the automation scripts in the proprietary language of a particular capture-replay tool
  2. You have to change to a different tool, but now you can't run any of your existing scripts without major work.

Questions

How to make sure that if and when the tool will have to be changed, you don't have to start again from scratch?

Resolving Patterns


Most recommended:

  • RIGHT TOOLS: use this pattern if your present tool doesn't fit the Software Under Test (SUT) well enough
  • TOOL INDEPENDENCE: this is the pattern of choice to solve this issue


Other useful patterns:

  • ABSTRACTION LEVELS: this pattern helps you separate the technical tool layer from the functional test cases
  • OBJECT MAP: use this pattern with all tools

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