REPETITIOUS TESTS

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

Issue summary

Test cases repeat the same actions on different data

Category

Design

Examples

A number of automated test cases are doing basically the same test, but using different data values. To test an ordering system, for instance, you have tests for different types of customer (new, existing, bad credit risk, etc) who order different types of things, different numbers of things at different values, different shipping options, etc. All of the tests have the same basic structure: enter a customer (name, address etc), items ordered, delivery option, and the sum that should be payable for that order.

If you have used capture replay, for example, each of these tests would be a separate script, but each script repeats the same basic control instructions, with the relevant data for the test within the test (programmers call this 'hard-coded' data). This approach guarantees high maintenance costs because these are BRITTLE SCRIPTS; they are repetitious because they all repeat (needlessly) the same instructions.

Questions

Are the test cases really similar? Moving the data out to a spreadsheet works if it is reasonably simple to construct a single control script, using the external data, to process all of the tests.

Resolving Patterns

Most recommended:

• DATA-DRIVEN TESTING: this pattern is one of the most applied in practice (even if nobody knows that it's a pattern!)

Other useful patterns:

• DON'T REINVENT THE WHEEL: applying this pattern will help you develop reusable testware
• REFACTOR THE TESTWARE: re-design the tests so that they are more efficient
  
  

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