VARIABLE DELAYS
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.