Best practices | TestCases | Wait times

A control is a specific screen element in your application under test: a button, a menu, a table cell, and so on.

Slow applications and dependencies between controls can lead to failed tests. Tosca doesn't distinguish between screens/controls that aren't there or screens/controls that aren't there yet. By default, Tosca waits up to 10 seconds for a screen or control, and then it reports an error.

Add wait times

To make your tests more stable, choose one of these options: 

  • Increase the default wait time, so Tosca waits longer than 10 seconds for any screen or control.

  • Add dynamic wait times, so Tosca waits until your application has reached a certain state. For example, if a progress bar has to reach 100% before the Next button activates.

  • Add static wait times, so Tosca pauses the test run for a defined amount of time. For example, if a page is a little slow to load.

All in all, we recommend that you avoid the last option—static wait times—if possible. Why? First, you need to know how long your application takes to load. If you define too little wait time, the test fails anyway. If you define too much wait time, the test takes unnecessarily long. And second, adapting static wait times costs extra effort as your application becomes faster and more reliable.

Increase the default wait time

To increase the default time that Tosca waits for any screen or control, change the setting Synchronization Timeout.

Use dynamic wait times

To add a dynamic wait time, use ActionMode WaitOn on the step that Tosca should wait on.

Tosca waits until the value of the progress bar property InnerText is 100% before it tries to click Next

By default, Tosca waits 20 seconds for all WaitOn TestSteps. If you need more or less time, change the setting Synchronization Timeout during WaitOn.

Use static wait times

If you really need to add a static wait time, choose one of these options: 

  • Add a wait time directly to a TestCase, by creating a TestStep with the Module TBox Wait.

  • Build wait time into a Module, by using the steering parameters WaitBefore or WaitAfter for a specific ModuleAttribute. Tosca applies the wait time you define to all TestCases where you use the Module and steer the respective control.

What's best for you depends on how consistently you need static wait times in your tests.

Using the TBox Wait Module is a quick solution if you only need a few static wait times here and there. However, if you want to change the wait time or remove it altogether, you have to modify all TestCases that have this step.

So, if you want to add a static wait time for a specific control across tests, the steering parameters WaitBefore or WaitAfter are a better choice. They're easier to maintain: to change the wait time or remove it entirely, simply modify the Module. Tosca automatically applies the change the next time you run the TestCases that use the Module.

Steering parameter WaitAfter for the ModuleAttribute Log In: always wait 25000 milliseconds after steering the Log In control

What's next

If you haven't yet, check out our other best practices articles.