Install any skill in seconds. Free to start, no credit card required.
Get Started Free →Perform actions and handle dynamic, async UI so tests adapt to change
.claude/skills/testdriverai-testdriver-performing-actions/SKILL.md| Test case | Without → With | Effect | Δ tokens | Δ turns |
|---|---|---|---|---|
| case-01 | ✗→✓ | ▲ Improved | -37% | 0% |
| case-02 | ✗→✓ | ▲ Improved | -43% | 0% |
| case-03 | ✗→✓ | ▲ Improved | -3% | 0% |
| case-04 | ✗→✓ | ▲ Improved | -42% | 0% |
| case-05 | ✗→✓ | ▲ Improved | -59% | 0% |
<!-- Generated from performing-actions.mdx. DO NOT EDIT. -->
Real apps move, load, and change. Adapt your tests to handle it.
Once you've generated and learned your tests and gotten them running, the next challenge is the real world: buttons appear after a spinner, pages navigate, animations play, and content streams in over the network. To keep tests reliable, you need to perform the right actions and handle timing so your tests adapt to how the UI actually behaves instead of breaking.
TestDriver provides a variety of actions you can perform, like clicking, typing, hovering, and scrolling. For a full list, see the API Reference.
javascript// Clicking await testdriver.find('submit button').click(); await testdriver.find('file item').doubleClick(); await testdriver.find('text area').rightClick(); // Typing await testdriver.find('email input').type('user@example.com'); await testdriver.find('password input').type('secret', { secret: true }); // Keyboard shortcuts await testdriver.pressKeys(['enter']); await testdriver.pressKeys(['ctrl', 'c']); // Hovering await testdriver.find('dropdown menu').hover(); // Scrolling await testdriver.scroll('down', 500); // Waiting await testdriver.wait(2000); // Wait 2 seconds for animation/state change // Extracting information from screen const price = await testdriver.extract('the total price'); const orderNumber = await testdriver.extract('the order confirmation number');
TestDriver supports method chaining for cleaner code:
javascript// Chain find() with actions const button = await testdriver.find('submit button').click();
Or save element reference for later use:
javascriptconst button = await testdriver.find('submit button'); await button.click();
By default, find() automatically polls for up to 10 seconds, retrying every 5 seconds until the element is found. This means most elements that appear after short async operations will be found without any extra configuration.
For longer operations, increase the timeout:
javascript// Default behavior - polls for up to 10 seconds automatically const element = await testdriver.find('Loading complete indicator'); await element.click(); // Wait up to 30 seconds for slower operations const element = await testdriver.find('Loading complete indicator', { timeout: 30000 }); await element.click(); // Useful after actions that trigger loading states await testdriver.find('submit button').click(); await testdriver.find('success message', { timeout: 15000 }); // Disable polling for instant checks const toast = await testdriver.find('notification toast', { timeout: 0 });
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.
<Note> Redraw detection adds a small delay after each action but significantly reduces test flakiness. </Note>
For example, when clicking a submit button that navigates to a new page:
javascript// Click submit - TestDriver automatically waits for the new page to load await testdriver.find('submit button').click(); // By the time this runs, the page has fully loaded and stabilized await testdriver.assert('dashboard is displayed'); await testdriver.find('welcome message');
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:
javascript// Disable redraw detection for faster tests (less reliable) const testdriver = TestDriver(context, { redraw: false });
Here is an example of customizing redraw detection:
javascript// Fine-tune redraw detection const testdriver = TestDriver(context, { redraw: { enabled: true, diffThreshold: 0.1, // Pixel difference threshold (0-1) screenRedraw: true, // Monitor screen changes networkMonitor: true, // Wait for network idle } });
wait()For simple pauses — waiting for animations, transitions, or state changes after an action — use wait():
javascript// Wait for an animation to complete await testdriver.find('menu toggle').click(); await testdriver.wait(2000); // Wait for a page transition to settle await testdriver.find('next page button').click(); await testdriver.wait(1000);
<Note> For waiting for specific elements to appear, prefer find() with a timeout option. Use wait() only for simple time-based pauses. </Note>
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.
<Card title="Next: Debug" icon="bug" href="/debugging-with-screenshots"> Use screenshots and run output to see exactly what your test saw and pinpoint failures. </Card>
| Case | Status | Duration (ms) | Turns | Tokens | Tool calls | ||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Without | With | Δ | Without | With | Δ | Without | With | Δ | Without | With | Δ | ||
case-01 | fail→pass | 10,201 | 16,988 | +67% | 1 | 1 | 0% | 1,785 | 1,116 | -37% | 0 | 0 | — |
case-02 | fail→pass | 10,757 | 3,838 | -64% | 1 | 1 | 0% | 1,949 | 1,108 | -43% | 0 | 0 | — |
case-03 | fail→pass | 7,726 | 3,175 | -59% | 1 | 1 | 0% | 1,017 | 982 | -3% | 0 | 0 | — |
case-04 | fail→pass | 8,605 | 2,338 | -73% | 1 | 1 | 0% | 1,433 | 826 | -42% | 0 | 0 | — |
case-05 | fail→pass | 9,609 | 1,974 | -79% | 1 | 1 | 0% | 1,622 | 673 | -59% | 0 | 0 | — |
case-06 | fail→pass | 6,238 | 2,091 | -66% | 1 | 1 | 0% | 1,026 | 696 | -32% | 0 | 0 | — |
case-07 | pass→pass | 7,245 | 2,129 | -71% | 1 | 1 | 0% | 1,172 | 728 | -38% | 0 | 0 | — |
case-08 | fail→pass | 8,935 | 1,632 | -82% | 1 | 1 | 0% | 1,486 | 625 | -58% | 0 | 0 | — |
case-09 | fail→pass | 8,522 | 1,985 | -77% | 1 | 1 | 0% | 1,381 | 709 | -49% | 0 | 0 | — |
case-10 | pass→pass | 6,577 | 1,892 | -71% | 1 | 1 | 0% | 1,014 | 673 | -34% | 0 | 0 | — |
case-11 | pass→pass | 10,118 | 2,266 | -78% | 1 | 1 | 0% | 1,586 | 753 | -53% | 0 | 0 | — |
case-12 | fail→pass | 3,509 | 1,757 | -50% | 1 | 1 | 0% | 482 | 581 | +21% | 0 | 0 | — |
case-13 | pass→pass | 3,411 | 1,806 | -47% | 1 | 1 | 0% | 553 | 662 | +20% | 0 | 0 | — |
case-14 | fail→pass | 7,957 | 2,236 | -72% | 1 | 1 | 0% | 1,259 | 688 | -45% | 0 | 0 | — |
case-15 | fail→pass | 5,202 | 1,763 | -66% | 1 | 1 | 0% | 764 | 617 | -19% | 0 | 0 | — |
case-16 | fail→pass | 9,270 | 3,919 | -58% | 1 | 1 | 0% | 1,651 | 1,066 | -35% | 0 | 0 | — |
case-17 | fail→pass | 12,361 | 4,078 | -67% | 1 | 1 | 0% | 1,982 | 1,016 | -49% | 0 | 0 | — |
case-18 | pass→pass | 6,632 | 2,192 | -67% | 1 | 1 | 0% | 1,092 | 613 | -44% | 0 | 0 | — |
case-19 | fail→pass | 5,722 | 1,682 | -71% | 1 | 1 | 0% | 982 | 623 | -37% | 0 | 0 | — |
case-20 | fail→pass | 6,610 | 5,236 | -21% | 1 | 1 | 0% | 1,191 | 1,209 | +2% | 0 | 0 | — |
case-21 | fail→fail | 12,797 | 7,197 | -44% | 1 | 1 | 0% | 2,211 | 1,293 | -42% | 0 | 0 | — |
case-22 | pass→pass | 11,798 | 6,500 | -45% | 1 | 1 | 0% | 1,816 | 1,297 | -29% | 0 | 0 | — |
DecimalAI ran this skill against gemini-3.6-flash twice over the same eval suite — once with the skill loaded and once without — and compared the two runs case by case. 22 cases were attempted. The headline lift of +68 percentage points is the difference between those two pass rates over the 22 comparable cases.
The publisher has shipped newer versions since this run, so these numbers describe v2, not the version currently listed.
Without the skill loaded, the model failed this case. With it loaded, the same prompt on the same model passed. This is one improved case from the latest verified run; every case, including any that regressed, is in the table above.
Other measured skills in the registry, with their headline benchmark lift.