@testkase/playwright-reporter

Drop-in integration for running existing Playwright tests on the TestKase Automate Browser cloud grid. Your test files + playwright.config.ts stay 100 % native Playwright — integration lives in a testkase.yml file + the testkase-playwright wrapper CLI.

Same shape as @lambdatest/playwright-node-sdk and browserstack-node-sdk.

Install

npm install --save-dev @testkase/playwright-reporter

⚠️ Version warning — read before following the rest of this page. The newest version published to npm is 0.5.6. The command above installs that. This README documents 0.6.0, which exists only in this working directory and has not been published — verified 2026-08-28 against the registry (npm view @testkase/playwright-reporter versions ends at 0.5.6).

Two documented features are therefore not available to any customer today:

• resolution: in testkase.yml — the string resolution does not appear anywhere in the published 0.5.6 dist/. Setting it has no effect.
• the viewport default changing to null ("the page fills the window") — see the 0.6.0 note below. Published sessions still render at Playwright's default 1280 × 720.

Everything else on this page is accurate against 0.5.6.

Set up testkase.yml

In your project root:

# Required
user:        [email protected]
accessKey:   xyz_…                   # from Settings → Access Key on the dashboard

# Required — which browser to drive (matches a TestKase brand)
browserName: Chrome                  # Chrome | Firefox | MicrosoftEdge | pw-firefox | pw-webkit

# Optional — but read the platformName note below before omitting it
build:        ci-${CI_BUILD_ID}      # groups sessions on the dashboard
name:         "checkout suite"       # default session name
platformName: MacOS Sequoia          # see the table below — Windows values too
browserVersion: latest               # omit → latest
headless:     false
tags:         [smoke, checkout]
resolution:   "1920x1080"            # remote browser WINDOW size — omit for the default (see below)

# Capture flags — all default OFF. Enable per kind for sessions you want to debug.
recording: true
console:   true
network:   true
driver:    true

# Page size. Omit it and the page FILLS the remote browser window (see below).
# Set it to pin a fixed page size instead.
# viewport:
#   width:  1280
#   height: 720

platformName — set it, or Chrome/Firefox/Edge sessions fail

The wrapper sends no default. If platformName is absent from testkase.yml, the Hub falls back to "linux" for every brand except Safari / WebKit — and there are no Linux browser builds in the fleet, so the session is refused with a 4404 and an "Available:" list. Treat this field as required unless you are running WebKit.

Accepted values (case-insensitive, automate-ws.ts PLATFORM_TO_OS_VERSION):

| Value | Runs on | |---|---| | MacOS Sequoia / MacOS 15 | macOS 15 | | MacOS Tahoe / MacOS 26 | macOS 26 | | MacOS | newest macOS in the fleet | | Windows 11 / Windows | Windows 11 | | Windows 10 | Windows 10 | | Linux | nothing today — reserved |

Anything else is rejected with a 4400. pw-webkit / Safari default to macOS on their own, so they are the one case where omitting it is safe.

Viewport: the page fills the window (changed in 0.6.0)

TestKase sizes the remote browser window to resolution — the whole remote screen when you don't set one — and from 0.6.0 the wrapper defaults Playwright's viewport to null so the page follows that window. Without both halves your session recording shows the remote desktop around a small page — the window and the viewport are two separate settings and either one alone leaves a border.

Before 0.6.0 every page rendered at Playwright's default 1280 × 720 regardless of the window. If your suite depends on that exact size (pixel screenshot comparisons, responsive breakpoints tuned to 1280 wide), pin it:

viewport:
  width:  1280
  height: 720

Anything you already set yourself always wins over the default — a viewport in your playwright.config.ts use block, a per-file test.use({ viewport }), or a viewport passed straight to browser.newContext().

Resolution: the size of the remote browser window

resolution: "1920x1080"

Omit it for the fleet default, 1920 × 1080. The value is a "WIDTHxHEIGHT" string and must be one of TestKase's standard resolutions — the wrapper forwards whatever you write and TestKase checks it, refusing the session with an explanatory message if it isn't on the list:

1024x768   1280x720   1280x800   1366x768
1440x900   1600x900   1920x1080  1920x1200
2560x1440  2560x1080  3440x1440* 3840x2160*

* macOS only — on Windows the recorder can't capture above 2560 × 2048, so those two are rejected there.

⚠️ On Windows sessions resolution currently has no effect on the desktop mode. The Hub validates and stores your value, and the two sizes above the Windows capture ceiling are rejected outright (below), but the in-guest /setdisplay call the agent makes does not exist on the fleet until an owner-gated base-image reseal — so a Windows guest keeps its default mode and logs one WARN per resolution-requesting session. macOS honours it today. (DeviceFarm:docs/products/automate-browser/RESOLUTION_PLAN.md, item 2.)

resolution sizes the remote browser window, not the remote desktop — the desktop can be larger. Only 6 of the 12 sizes above are also a display mode the remote macOS machine has, and a pick that isn't one runs in a window of exactly the size you asked for on the next mode up: ask for 1366x768 and you get a 1366 × 768 window on a 1600 × 900 desktop, with a border on two sides. That is why this setting is a window size and not a screen size.

The viewport default above (null) is what makes the page fill that window. They are two separate settings: pin viewport to a fixed {width, height} as well and a larger resolution just gives you more remote desktop around the same-sized page.

The same option is available on the direct-connect path as tkWsEndpoint({ resolution: "1920x1080" }) — there the viewport is yours to set, so pass viewport: null to newContext() / newPage() if you want the page to fill the window.

Run

# Drop-in replacement for `npx playwright test`
npx testkase-playwright test

# All Playwright flags pass through
npx testkase-playwright test --project=chrome --grep=checkout --headed

That's it. Your test files stay unchanged:

// tests/checkout.spec.ts — 100 % native Playwright, no TestKase imports
import { test, expect } from "@playwright/test";

test("user can place an order", async ({ page }) => {
  await test.step("login", async () => {
    await page.goto("/login");
    await page.fill("#email", "[email protected]");
    await page.click("text=Sign in");
  });
  // …
});

What lights up automatically:

• Test rail populates with test.title / pass-fail status per test
• Test Output sub-tab gets one line per test.step("label", …) call
• Browser Console + Network capture on Chrome (CDP) AND Firefox (Playwright page.on('console') / page.on('request'))
• Recording + Driver logs as always
• Per-test MP4 slicing — fresh ffmpeg per test, finalized + uploaded at test end

All four kinds (console.jsonl.gz, network.har.jsonl.gz, driver.jsonl.gz, test-output.jsonl.gz) land on R2 at session end and render live during the run.

Multi-browser via Playwright's projects

// playwright.config.ts — purely native Playwright, no TestKase imports
import { defineConfig } from "@playwright/test";

export default defineConfig({
  projects: [
    { name: "chrome",  use: { browserName: "chromium" } },
    { name: "firefox", use: { browserName: "firefox"  } },
  ],
});

Run the same test file against both:

npx testkase-playwright test                    # both browsers
npx testkase-playwright test --project=firefox  # one

The wrapper picks the matching TestKase brand for each project (chromium → Chrome, firefox → Firefox).

Credentials via env vars (CI-friendly)

YAML values support env interpolation, and user / accessKey fall back to env vars:

# testkase.yml — commit-safe
build: ${BUILD:-local}
# user + accessKey fall back to TK_USERNAME + ACCESS_KEY env vars when omitted

export [email protected]
export ACCESS_KEY=xyz_…
export BUILD=ci-1234
npx testkase-playwright test

Alternative: chromium.connect() style (no wrapper CLI)

If you can't run a wrapper CLI (locked-down CI, custom runners), you can connect to the TestKase hub directly. Capture coverage drops to what's available without our preload:

• Chrome / Edge: full coverage (Recording, Driver, Console, Network via server-side cdp-tap)
• Firefox: Recording + Driver only (Mozilla protocol doesn't allow a server-side 3rd-party tap)
• Test rail + Test Output: only if you manually emit testkase_action: magic strings (see LambdaTest's Direct docs for the equivalent pattern)

import { chromium } from "@playwright/test";
import { tkWsEndpoint } from "@testkase/playwright-reporter";

// tkWsEndpoint is exported as a helper to build the wss:// URL with
// capabilities baked in — same caps the wrapper CLI sets via YAML.
const browser = await chromium.connect(
  tkWsEndpoint({
    name: "smoke",
    browserName: "Chrome",
    recording: true,
    console: true,
    network: true,
    driver: true,
  }),
);

What gets installed

| File | Purpose | |---|---| | dist/cli.cjs | testkase-playwright bin | | dist/preload.cjs | Loaded via NODE_OPTIONS=--require by the CLI; mutates @playwright/test cached exports | | dist/index.{js,cjs,d.ts} | Direct API surface (tkWsEndpoint, attachTestkaseCapture, tklog, wrapped firefox/chromium/webkit, extended test) |

Peer dep: @playwright/test >= 1.10.0. Runtime dep: yaml.

Per-browser feature coverage

| Feature | Chrome | Edge | Firefox | |---|---|---|---| | Recording (MP4) | ✅ | ✅ | ✅ | | Driver logs | ✅ | ✅ | ✅ | | Browser Console | ✅ | ✅ | ✅ 118+ | | Network HAR | ✅ | ✅ | ✅ 123+ | | Test rail (name + status) | ✅ | ✅ | ✅ | | Test Output (step labels) | ✅ | ✅ | ✅ | | Per-test recording slicing | ✅ | ✅ | ✅ | | Commands tab | ✅ | ✅ | ✅ | | Live View (WebRTC) | ✅ | ✅ | ✅ |

Firefox capture has version floors

Firefox capture rides WebDriver BiDi, and the two modules landed in different releases. On Firefox below 118 the Console tab is empty, and below 123 the Network tab is empty — the session still runs and still records, you just get no rows. Chrome and Edge use CDP and have no floor.

Those numbers come from an empirical sweep of all 39 Firefox majors (113–151) run 2026-07-11 on the same BiDi module and geckodriver 0.37, macOS and Windows (DeviceFarm:docs/products/automate-browser/SELENIUM.md:252). They supersede an earlier release-timeline estimate of console 113 / network 129 that was never swept — if you find 113/129 quoted anywhere, including in testkase-frontend/src/lib/errors/automate-error-messages.ts:311-312, the swept numbers above are the correct ones and the constant is a known open bug.

License

MIT