Test Speed Optimization

See the duration breakdown for your tests

On every test detail page in the member dashboard, hover over the Duration value to see a breakdown of the session: how much time was spent on setup versus execution, and which capabilities impacted the session speed. Each capability in the popover links to the matching section on this page.

Optimize TestingBot Time

TestingBot Time is everything between requesting a session and its completion. It is the sum of two parts:

• Setup time: queue time plus preparing the browser, emulator, simulator or physical device, before your first command runs.
• Execution time: the time your test commands spend running on the browser or device.

Reduce setup time

• Stay within your concurrency limit. Sessions started beyond your plan's parallel limit wait in a queue until a slot frees up. Spread test starts over time, or upgrade the number of parallel sessions if your suite regularly queues.
• Prefer virtual devices for broad coverage. Android emulators and iOS simulators are prepared faster than physical devices. Use virtual devices for functional coverage and reserve physical devices for final verification.
• Only set the session capabilities you need. Capabilities such as timeZone, screen-resolution, prerun and firefox_profile each add work before the session is ready. The capability sections below explain the cost of each one.
• Reuse uploaded apps. For mobile app tests, upload your app once and reference it with its tb:// app key instead of uploading the binary again for every session.
• Set a realistic client connection timeout. iOS simulators and Android emulators can take 60 to 120 seconds to boot. If your test runner gives up earlier, the session is cancelled and retried, which wastes the whole setup. See new session cancelled before test start.

Reduce execution time

• Use explicit waits instead of fixed sleeps. A sleep(5) always costs 5 seconds; an explicit wait continues the moment the element is ready.
• Keep tests atomic and run them in parallel. Many short, independent tests finish faster than one long journey, because they spread across your parallel sessions and a failure does not invalidate unrelated steps.
• Quit the session as soon as the test ends. Always call driver.quit() in a teardown block. A session without it stays open until the idle timeout hits, adding up to 90 seconds per test.
• Prefer fast selectors. ID and CSS selectors are resolved faster than complex XPath expressions, especially on large pages.
• Report status through the API. Use test annotations or the REST API to mark a test passed or failed instead of adding extra in-browser steps for reporting.
• Avoid large downloads and uploads during the test. Every file transferred through the browser session adds time. Keep fixtures small and mock heavy network responses where possible.

Optimize Capabilities Impacting Session

Some capabilities add processing while the session is being prepared or while your commands run. The duration breakdown popover on the test detail page flags the ones detected in your session with a high, medium or low impact badge. Each section below explains the cost and how to reduce it.

screenrecorder (high impact)

Video recording is enabled by default for every session. Encoding the video runs for the entire duration of the test and finalizing the file adds time when the session completes. If you do not need a recording, for example on large regression suites or consistently green builds, disable it with screenrecorder: false.

tunnel (high impact)

With TestingBot Tunnel, browser traffic is routed through the secure tunnel to your machine, so every request pays extra network latency. Start the tunnel once and share it across all tests in the run instead of starting one per test, run the tunnel process close to the servers under test, and only enable it for tests that genuinely need access to internal or staging environments.

geoCountryCode (high impact)

geoCountryCode routes all browser traffic through a proxy server in the selected country. Each request travels an extra round trip to that proxy. Only use it for tests that verify geolocation-specific behavior, and keep the rest of your suite on a direct connection.

prerun (high impact)

A prerun executable is downloaded and executed on the test VM before your session starts, so its full runtime is added to setup time. Keep prerun scripts small and fast, and prefer building one-time configuration into the app or the test itself.

firefox_profile (high impact)

A custom Firefox profile is uploaded and extracted on the VM during setup. The larger the profile, the longer the session takes to start. Keep the profile minimal: only the preferences and extensions the test actually needs.

screenshot (medium impact)

With screenshot: true, TestingBot captures a screenshot during the test, which adds overhead per captured step. For large suites, disable automatic screenshots and take targeted screenshots from your test code only where they add debugging value.

timeZone (medium impact)

Setting a custom timeZone reconfigures the operating system clock before the session starts. Only set it for tests that assert timezone-dependent behavior.

deviceOrientation (medium impact)

Starting a mobile session in landscape requires rotating the device or emulator during setup. Use the default portrait orientation unless the test specifically covers landscape layouts, and rotate from within the test only when needed.

realDevice (medium impact)

Physical devices are cleaned and prepared between sessions, which takes longer than booting an emulator or simulator. Use virtual devices for day-to-day functional coverage and schedule physical-device runs where real hardware matters: sensors, performance characteristics and vendor-specific behavior.

screen-resolution (low impact)

Changing the screen-resolution switches the display mode of the VM during setup. Use the default resolution unless your test verifies a specific viewport, and prefer resizing the browser window from within the test when that is all you need.

locale (low impact)

Custom locale or language values are configured on the device or emulator during setup. Only set them for localization tests.