TestDriver vs Cucumber
Feature checklists rarely decide anything. What decides it is the pricing metric, who has to write the tests, and which limitation you can live with.
Entry price
From $20 per seat/month (120 testing minutes included, then $0.14/minute)
Free tierFree tier available
Free tierWhat drives the bill
The metric that actually scales your invoice.
The seat price is the small half of the bill: $20 per seat covers 120 testing minutes, then metering kicks in at $0.14 a minute (about $8.40 an hour). Seats are billed for every GitHub user who gets a PR review or runs a test, and a vision model driving a desktop is slower per test than a headless browser — model the minutes before committing a large suite.
Open source core. SmartBear sells CucumberStudio for collaborative scenario authoring, priced per user on request.
Free tier
Free trial rather than a standing free tier; paid seats include 120 testing minutes a month.
The Cucumber libraries are open source and free.
Open source
MIT (core)
Self-hostable
No-code authoring
Languages
Platforms
Fits teams
Adoption
Niche
TestDriver
Widely used
Smartbear · since 2008
Strengths
- Tests surfaces nothing else reaches — browser extensions, packaged desktop apps, canvas and third-party OAuth screens.
- No selectors to maintain, so a refactor that renames every class breaks nothing.
- Runs per pull request in a disposable sandbox rather than against a shared staging environment.
- Shared vocabulary between product, QA and engineering when the practice is actually followed.
- Scenarios double as living documentation that stays honest because it executes.
- Available in every major language.
Limitations
- A vision model is non-deterministic. Reruns of an unchanged test do not always take the same path, which makes a genuine failure harder to distinguish from a bad frame.
- Billed by testing hours, and driving a real desktop is slow — a suite that costs pennies on Playwright can cost real money here.
- Young product with a small community; expect to be an early reporter of your own bugs.
- Almost always adopted as a syntax rather than a collaboration practice, at which point it is pure overhead on top of your real tests.
- The step-definition layer is a second codebase to maintain and refactor.
- Gherkin obscures technical detail that developers need when a test fails.
Best for
Teams testing extensions, desktop apps or canvas-heavy UIs, where selector-based runners simply cannot see the thing under test.
Teams genuinely practising BDD with three-amigos sessions, not teams who just want prettier test names.
Pricing last reviewed August 2026 and is indicative only — confirm on each vendor’s own page.