Difference between revisions of "TOOL INDEPENDENCE"

From Test Automation Patterns
Jump to navigation Jump to search
m (Topic titles in capital letters)
Line 1: Line 1:
 
<div id="content_view" class="wiki" style="display: block"><span style="font-size: 14px">.................................................................................................................[[Main Page]] / Back to [[Design Patterns]] / Back to [[Test Automation Patterns]]</span>
 
<div id="content_view" class="wiki" style="display: block"><span style="font-size: 14px">.................................................................................................................[[Main Page]] / Back to [[Design Patterns]] / Back to [[Test Automation Patterns]]</span>
=<span style="font-size: 16px">Pattern summary</span>=
+
=<span style="font-size: 16px">'''Pattern summary'''</span>=
 
<span style="font-size: 16px">Separate the technical implementation that is specific for the tool from the functional implementation of the tests.</span>
 
<span style="font-size: 16px">Separate the technical implementation that is specific for the tool from the functional implementation of the tests.</span>
=<span style="font-size: 16px">Category</span>=
+
=<span style="font-size: 16px">'''Category'''</span>=
 
<span style="font-size: 16px">Design</span>
 
<span style="font-size: 16px">Design</span>
=<span style="font-size: 16px">Context</span>=
+
=<span style="font-size: 16px">'''Context'''</span>=
 
<span style="font-size: 16px">This pattern is applicable if you want to run automated tests on multiple platforms or environments, or if the tool you are using might change at some point (which is more likely the longer you have automated tests!)</span><br /> <span style="font-size: 16px">This pattern is not applicable for short-term automation, e.g. disposable scripts.</span>
 
<span style="font-size: 16px">This pattern is applicable if you want to run automated tests on multiple platforms or environments, or if the tool you are using might change at some point (which is more likely the longer you have automated tests!)</span><br /> <span style="font-size: 16px">This pattern is not applicable for short-term automation, e.g. disposable scripts.</span>
=<span style="font-size: 16px">Description</span>=
+
=<span style="font-size: 16px">'''Description'''</span>=
 
<span style="font-size: 16px">Design the structure for the testware so that tool-specific elements are kept to a minimum. Make the scripts modular, where tool-specific scripts are called by the scripts implementing the tests. </span>
 
<span style="font-size: 16px">Design the structure for the testware so that tool-specific elements are kept to a minimum. Make the scripts modular, where tool-specific scripts are called by the scripts implementing the tests. </span>
=<span style="font-size: 16px">Implementation</span>=
+
=<span style="font-size: 16px">'''Implementation'''</span>=
 
<span style="font-size: 16px">Some suggestions:</span><br />  
 
<span style="font-size: 16px">Some suggestions:</span><br />  
  
Line 15: Line 15:
 
* <span style="font-size: 16px; line-height: 24px">Use [[GOOD PROGRAMMING PRACTICES]] to keep tool-specific aspects in a small number of scripts that can be called by other scripts.</span>
 
* <span style="font-size: 16px; line-height: 24px">Use [[GOOD PROGRAMMING PRACTICES]] to keep tool-specific aspects in a small number of scripts that can be called by other scripts.</span>
  
=<span style="font-size: 16px">Potential problems</span>=
+
=<span style="font-size: 16px">'''Potential problems'''</span>=
 
<span style="font-size: 16px">The effort spent on making testware separate from tool-specific aspects may be considered a waste of time by those who cannot see that the tool "engine" will change in the future.</span>
 
<span style="font-size: 16px">The effort spent on making testware separate from tool-specific aspects may be considered a waste of time by those who cannot see that the tool "engine" will change in the future.</span>
=<span style="font-size: 16px">Issues addressed by this pattern</span>=
+
=<span style="font-size: 16px">'''Issues addressed by this pattern'''</span>=
 
''<span style="font-size: 16px">[[HIGH ROI EXPECTATIONS]]</span>''<br /> ''<span style="font-size: 16px">[[OBSCURE TESTS]]</span>''<br /> ''<span style="font-size: 16px">[[TOOL DEPENDENCY]]</span>''
 
''<span style="font-size: 16px">[[HIGH ROI EXPECTATIONS]]</span>''<br /> ''<span style="font-size: 16px">[[OBSCURE TESTS]]</span>''<br /> ''<span style="font-size: 16px">[[TOOL DEPENDENCY]]</span>''
=<span style="font-size: 16px">Experiences</span>=
+
=<span style="font-size: 16px">'''Experiences'''</span>=
<span style="font-size: 16px">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!</span><br /> <br /> <span style="font-size: 14px">.................................................................................................................[[Main Page]] / Back to [[Design Patterns]] / Back to [[Test Automation Patterns]]</span>
+
<span style="font-size: 16px">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!</span><br /> <span style="font-size: 16px">Example</span>
=<span style="font-size: 16px">Example</span>=
 
 
<span style="font-size: 16px">Seretta:</span><br />  
 
<span style="font-size: 16px">Seretta:</span><br />  
 
{| class="wiki_table"
 
{| class="wiki_table"
| <span style="font-size: 16px">In my company we use [[Command-Driven Testing]], a variation of [[KEYWORD-DRIVEN TESTING]] that enables us to write scripts that are in fact tool independent.</span><br /> <span style="font-size: 16px">The trick is that our keywords are just plain commands that don’t contain any domain specific information. The test scripts use the keywords to specify how the SUT has to be driven for a particular test.</span><br /> <span style="font-size: 16px">To show how this works, here is an extract from one the scripts that we use to test our own test automation framework:</span><br /> <span style="font-size: 16px">…….</span><br />
+
| <span style="font-size: 16px">In my company we use Command-Driven Testing, a variation of [[KEYWORD-DRIVEN TESTING]] that enables us to write scripts that are in fact tool independent.</span><br /> <span style="font-size: 16px">The trick is that our keywords are just plain commands that don’t contain any domain specific information. The test scripts use the keywords to specify how the SUT has to be driven for a particular test.</span><br /> <span style="font-size: 16px">To show how this works, here is an extract from one the scripts that we use to test our own test automation framework:</span><br /> <span style="font-size: 16px">…….</span><br />
 
  <span style="font-size: 16px">GOTO,FTestSuite</span><br /> <span style="font-size: 16px"> INPUT,ComboBox,cboPriority,<Priority></span><br /> <span style="font-size: 16px"> INPUT,ComboBox,cboTestType,<TestType></span><br /> <span style="font-size: 16px"> SELECT,Button,<ButtonDRIVER></span><br /> <span style="font-size: 16px"> GOTO,<SelectDirDRIVER></span><br /> <span style="font-size: 16px"> INPUT,edtDirectory,<DRIVERDirName></span><br /> <span style="font-size: 16px"> SELECT,Button,<ConfirmSelectionDRIVER></span><br /> <span style="font-size: 16px">…….</span><br />
 
  <span style="font-size: 16px">GOTO,FTestSuite</span><br /> <span style="font-size: 16px"> INPUT,ComboBox,cboPriority,<Priority></span><br /> <span style="font-size: 16px"> INPUT,ComboBox,cboTestType,<TestType></span><br /> <span style="font-size: 16px"> SELECT,Button,<ButtonDRIVER></span><br /> <span style="font-size: 16px"> GOTO,<SelectDirDRIVER></span><br /> <span style="font-size: 16px"> INPUT,edtDirectory,<DRIVERDirName></span><br /> <span style="font-size: 16px"> SELECT,Button,<ConfirmSelectionDRIVER></span><br /> <span style="font-size: 16px">…….</span><br />
 
<span style="font-size: 16px">The commands GOTO, INPUT or SELECT are then implemented in the specific script language of our tool. If we want to use another tool we have to duplicate this implementation (GOTO, INPUT or SELECT) in the script language of the second tool, but our test script doesn’t have to be changed. (In practice we also must make sure that the GUI-objects that we need to drive get the same names in both tools. For further explanations look up the pattern [[OBJECT MAP]]</span>.)<br /> <span style="font-size: 16px">Since the number of commands doesn’t usually exceed 30-50, this is much cheaper than having to rewrite all the functional test scripts!</span><br />
 
<span style="font-size: 16px">The commands GOTO, INPUT or SELECT are then implemented in the specific script language of our tool. If we want to use another tool we have to duplicate this implementation (GOTO, INPUT or SELECT) in the script language of the second tool, but our test script doesn’t have to be changed. (In practice we also must make sure that the GUI-objects that we need to drive get the same names in both tools. For further explanations look up the pattern [[OBJECT MAP]]</span>.)<br /> <span style="font-size: 16px">Since the number of commands doesn’t usually exceed 30-50, this is much cheaper than having to rewrite all the functional test scripts!</span><br />
 
|}
 
|}
 
<br /> <br /> <br /> <span style="font-size: 14px">.................................................................................................................[[Main Page]] / Back to [[Design Patterns]] / Back to [[Test Automation Patterns]]</span></div>
 
<br /> <br /> <br /> <span style="font-size: 14px">.................................................................................................................[[Main Page]] / Back to [[Design Patterns]] / Back to [[Test Automation Patterns]]</span></div>

Revision as of 11:01, 29 April 2018

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

Pattern summary

Separate the technical implementation that is specific for the tool from the functional implementation of the tests.

Category

Design

Context

This pattern is applicable if you want to run automated tests on multiple platforms or environments, or if the tool you are using might change at some point (which is more likely the longer you have automated tests!)
This pattern is not applicable for short-term automation, e.g. disposable scripts.

Description

Design the structure for the testware so that tool-specific elements are kept to a minimum. Make the scripts modular, where tool-specific scripts are called by the scripts implementing the tests.

Implementation

Some suggestions:

  • Use a TEST AUTOMATION FRAMEWORK that supports KEYWORD-DRIVEN TESTING or DOMAIN-DRIVEN TESTING. Having separated the functional scripts from the tool-dependent ones means that if you change the tool, you only have to rewrite the tool-specific command scripts and all the others can be used without change.
  • Use an OBJECT MAP to name the GUI elements in your application. If you change your tool, you will have to map the GUI elements again in the new tool, but you will not need to change the functional scripts.
  • Use GOOD PROGRAMMING PRACTICES to keep tool-specific aspects in a small number of scripts that can be called by other scripts.

Potential problems

The effort spent on making testware separate from tool-specific aspects may be considered a waste of time by those who cannot see that the tool "engine" will change in the future.

Issues addressed by this pattern

HIGH ROI EXPECTATIONS
OBSCURE TESTS
TOOL DEPENDENCY

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!
Example Seretta:

In my company we use Command-Driven Testing, a variation of KEYWORD-DRIVEN TESTING that enables us to write scripts that are in fact tool independent.
The trick is that our keywords are just plain commands that don’t contain any domain specific information. The test scripts use the keywords to specify how the SUT has to be driven for a particular test.
To show how this works, here is an extract from one the scripts that we use to test our own test automation framework:
…….
GOTO,FTestSuite
INPUT,ComboBox,cboPriority,<Priority>
INPUT,ComboBox,cboTestType,<TestType>
SELECT,Button,<ButtonDRIVER>
GOTO,<SelectDirDRIVER>
INPUT,edtDirectory,<DRIVERDirName>
SELECT,Button,<ConfirmSelectionDRIVER>
…….

The commands GOTO, INPUT or SELECT are then implemented in the specific script language of our tool. If we want to use another tool we have to duplicate this implementation (GOTO, INPUT or SELECT) in the script language of the second tool, but our test script doesn’t have to be changed. (In practice we also must make sure that the GUI-objects that we need to drive get the same names in both tools. For further explanations look up the pattern OBJECT MAP.)
Since the number of commands doesn’t usually exceed 30-50, this is much cheaper than having to rewrite all the functional test scripts!




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