VARIABLE DELAYS

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

Pattern summary

Use variable delays based on events, not fixed delays based on elapsed time

Category

Execution

Context

Use this pattern to make your test run as fast and as efficiently as possible

Description

When SUT execution is slow it may be necessary to add delays to the automation script. Fixed length delays should be avoided, because in order to account for different test environments, traffic situations and so on you have to use the longest possible pause. New generation tools offer the possibility to wait only until an event happens. The tool will wait the given maximum wait-time only if the event doesn’t occur at all.

Implementation

The actual implementation depends not only on the tool you are using, but also on how the System under Test (SUT) has been developed. Some suggestions when developing variable delays:

If the SUT shows when an action has been terminated, check it and delay execution until it switches auf true:

• a window disappears or appears
• a GUI-Component is enabled or disabled
• a database field is updated

With files, folders or databases there are usually parameters that tell the system to wait until the action is done

Issues addressed by this pattern

FLAKY TESTS
HARD-TO-AUTOMATE
INEFFICIENT EXECUTION
MANUAL INTERVENTIONS

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 Execution Patterns / Back to Test Automation Patterns