Skip to main content
Real apps move, load, and change. Adapt your tests to these conditions. You generated and learned your tests. Then you got them to run. Now the challenge is the real world: buttons show after a spinner, pages navigate, animations play, and content comes in over the network. To keep the tests reliable, do the correct actions and control the timing. Then your tests adapt to the true behavior of the UI. They do not break.

Performing Actions

TestDriver gives you many actions. You can click, type, hover, and scroll. For a full list, read the API Reference.

Chaining Actions

TestDriver lets you chain methods for cleaner code:
Or keep the element reference for later use:

Waiting for Dynamic Content

By default, find() polls automatically for a maximum of 10 seconds. It tries again each 5 seconds until it finds the element. Thus TestDriver finds most elements that show after short async operations. You do not need more configuration. For longer operations, make the timeout larger:

Flake Prevention

TestDriver automatically waits for the screen and network to stabilize after each action using redraw detection. This prevents flaky tests caused by animations, loading states, or dynamic content updates.
Redraw detection adds a small delay after each action but significantly reduces test flakiness.
For example, when clicking a submit button that navigates to a new page:
Without redraw detection, you’d need manual waits or retries to handle the page transition. TestDriver handles this automatically by detecting when the screen stops changing and network requests complete. You can disable redraw detection or customize its behavior:
Here is an example of customizing redraw detection:

Simple Delays with wait()

For simple pauses — waiting for animations, transitions, or state changes after an action — use wait():
For waiting for specific elements to appear, prefer find() with a timeout option. Use wait() only for simple time-based pauses.
Once your tests can reliably act on a changing UI and assert the results, the next step is figuring out what happened when something does go wrong.

Next: Debug

Use screenshots and run output to see exactly what your test saw and pinpoint failures.