feat(providers): add TestingBot cloud provider#118
Conversation
Adds TestingBot at parity with BrowserStack, Sauce Labs, and TestMu: browser + mobile sessions, auto-start tunnel via testingbot-tunnel-launcher, upload_app/list_apps through TestingBot Storage, pass/fail result marking, generated reproduction code, and the wdio://testingbot/local-binary resource. Credentials: TESTINGBOT_KEY / TESTINGBOT_SECRET. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Greptile SummaryThis PR adds TestingBot as a fourth cloud provider, slotting into the established
Confidence Score: 5/5Safe to merge — the change is purely additive, follows the existing provider pattern faithfully, and carries comprehensive unit test coverage. The provider correctly handles all three session modes, tunnel lifecycle uses close() on the specific handle (not a global kill), and the result-marking path is well-tested. Two style-level items were found in the generated code (unused tunnel variable) and provider (dead testingbotLocal fallback), neither of which affects runtime correctness. No files require special attention. The two findings in code-generator.ts and testingbot.provider.ts are clean-up items with no functional impact.
|
| Filename | Overview |
|---|---|
| src/providers/cloud/testingbot.provider.ts | New TestingBotProvider implementing all three capability modes. stopTunnel correctly uses close() callback. Dead-code nit: options.testingbotLocal in buildCapabilities is never populated. |
| src/recording/code-generator.ts | TestingBot code generation added. The tunnel variable from downloadAndRunAsync is unused because stopTunnel calls killAsync() instead of tunnel.close(). |
| src/tools/cloud-provider.tool.ts | TestingBot config block added with correct null guards. Enum widening is consistent. |
| src/resources/testingbot-local.resource.ts | Resource definition for wdio://testingbot/local-binary following the established pattern. |
| src/types/testingbot-tunnel-launcher.d.ts | Type shim for untyped testingbot-tunnel-launcher package. Accurately models the API. |
| tests/providers/testingbot.provider.test.ts | Comprehensive unit tests covering all three capability modes, tunnel lifecycle, and error paths. |
| tests/tools/cloud-provider.tool.test.ts | TestingBot list/upload tests added covering success, response parsing, and missing-credentials error path. |
Sequence Diagram
sequenceDiagram
participant Client as MCP Client
participant SessionTool as start_session tool
participant Registry as providers/registry.ts
participant TBProvider as TestingBotProvider
participant TBTunnel as testingbot-tunnel-launcher
participant TBAPI as api.testingbot.com
participant Hub as hub.testingbot.com
Client->>SessionTool: "start_session({ provider: 'testingbot', tunnel: true, ... })"
SessionTool->>Registry: getProvider('testingbot', platform)
Registry-->>SessionTool: TestingBotProvider
SessionTool->>TBProvider: buildCapabilities(options)
TBProvider-->>SessionTool: "{ browserName, platformName, tb:options, ... }"
SessionTool->>TBProvider: startTunnel(options)
TBProvider->>TBTunnel: "downloadAndRunAsync({ apiKey, apiSecret, tunnelIdentifier })"
TBTunnel-->>TBProvider: tunnelHandle
TBProvider-->>SessionTool: tunnelHandle
SessionTool->>Hub: POST /wd/hub (WebDriver session with capabilities)
Hub-->>SessionTool: sessionId
Note over Client,Hub: Session active — test steps execute
Client->>SessionTool: "close_session({ status: 'passed' })"
SessionTool->>TBProvider: onSessionClose(sessionId, type, result)
TBProvider->>TBAPI: "PUT /v1/tests/:sessionId (test[success]=1)"
TBAPI-->>TBProvider: 200 OK
SessionTool->>TBProvider: stopTunnel(tunnelHandle)
TBProvider->>TBTunnel: tunnel.close(callback)
TBTunnel-->>TBProvider: callback()
Reviews (2): Last reviewed commit: "fix(testingbot): make tunnel-already-run..." | Re-trigger Greptile
Winify
left a comment
There was a problem hiding this comment.
Approved 🎉 publishing this as 3.7.0
Proposed changes
Adds TestingBot as a cloud provider, at feature parity with the existing BrowserStack, Sauce Labs, and TestMu integrations. It slots into the established
SessionProviderpattern (src/providers/) — one provider class plus the usual enum/dispatch widening — and follows the same shape as the TestMu integration in #116.New Provider (src/providers/cloud/testingbot.provider.ts)
TestingBotProviderimplements theSessionProviderinterface with three capability modes (browser, mobile browser/emulator, mobile native app), tunnel lifecycle viatestingbot-tunnel-launcher, and session result reporting via the TestingBot REST API. UsesTESTINGBOT_KEY/TESTINGBOT_SECRETenvironment variables (mapped to WebDriveruser/key); credentials never appear in tool call parameters. Hub:hub.testingbot.com, capability blocktb:options.App Management (src/tools/cloud-provider.tool.ts)
list_appsfor TestingBot fetchesGET /v1/storage(single call — no per-platform split needed) and returnstb://refs.upload_appuploads toPOST /v1/storage(multipart fieldfile), returns thetb://app URL for use instart_session.Result Marking
PUT https://api.testingbot.com/v1/tests/:idwith form-encodedtest[success]=1|0. A single code path covers both web and mobile sessions — the:idroute accepts the WebDriver session UUID, so there's no web-REST / mobile-executesplit.Tunnel Binary Resource (src/resources/testingbot-local.resource.ts)
wdio://testingbot/local-binaryresource with the TestingBot Tunnel download URL and setup commands, matching the BrowserStack/Sauce Labs/TestMu pattern. Note: the TestingBot Tunnel is a single cross-platform Java JAR (requires Java 11+) rather than per-platform native binaries.Also adds
tb:optionsdetection to the code generator (wdio://session/current/code), a type shim for the untypedtestingbot-tunnel-launcherpackage, and README/CLAUDE.md documentation.Types of changes
Checklist
Further comments
Testing:
npm testpasses (411 tests across 30 files), including a newtestingbot.provider.test.tssuite plus registry and cloud-tool cases.npm run lintis clean (0 errors) andnpm run bundlebuilds. A live end-to-end browser session against a real TestingBot account was run and verified (session and pass/fail result confirmed on the TestingBot dashboard).Design notes:
TESTINGBOT_KEY/TESTINGBOT_SECRETnaming (matches TestingBot docs and the@wdio/testingbot-serviceconvention) rather than the*_USERNAME/*_ACCESS_KEYshape of the other providers.platformNametoWindows 11whenosis omitted (TestingBot's most broadly available platform); overridable viaos/osVersion.testingbotLocalalias was added — this is a new provider, so it uses only the unifiedtunnelparameter.Reviewers: @webdriverio/project-committers