Anyone who has triaged a flaky end-to-end test from a CI log alone knows the drill: a red checkmark, a stack trace that explains what failed but not why, and a Slack thread full of "can you repro locally?" With Webship-JS 2.0.x, video recording stops being an afterthought bolted onto your test runner and becomes a first-class Gherkin citizen, controllable from the same feature files that describe your test scenarios.

Why bake the video into the BDD layer?

Webship-JS is a BDD-first browser automation harness built on Playwright and Cucumber-js. The pitch is simple: write plain Gherkin, get smart waits, a named-selector registry, and web-first assertions, all without sleep() calls scattered through your step definitions.

Video recording fits that same philosophy. Playwright already supports recording a browser context to WebM via its recordVideo option, that part isn't new. What Webship-JS adds is a small set of step phrasings that let you start, stop, and save that recording directly inside a scenario, rather than wiring it up in config and hoping the right context gets it. That matters most for distributed teams: someone on a different continent doesn't need to reproduce a failure locally if the video is already sitting next to the test report.

The four steps

Webship-JS ships a dedicated video step group with four phrasings:

When I start video recording
When I stop video recording
When I save the current video as "checkout-flow.webm"
Then print video path

Here's what each one actually does:

When I start video recording, Begins recording the browser as a WebM video. Under the hood this means the current page is closed so a fresh context can be opened with recordVideo enabled. Playwright only captures video for contexts created with that option set, so a clean handoff is required.
When I stop video recording, Ends the recording. This closes the page and the context, which is what flushes the WebM file to disk. Playwright doesn't finalize a video until its context shuts down, so this step is doing real cleanup work, not just a label.
When I save the current video as "checkout-flow.webm", Reserves a custom filename for the current scenario's recording instead of leaving it with an auto-generated name. Handy when you want checkout-flow.webm sitting in CI artifacts rather than a hash you have to cross-reference against a test report.
Then print video path, A diagnostic step that prints out the path the current video will be written to. Useful when you're debugging the recording setup itself, or just confirming a CI job is writing where you expect.

What this looks like in a feature file

Because the steps are just Gherkin, they read like any other part of your scenario:

Feature: Login page
  Scenario: Successful login
    When I start video recording
    Given I am on homepage
     When I go to "login.html"
      And I fill in "Username" with "Smith"
      And I fill in "Password" with "1$34"
      And I press "Login"
     Then I should see "Welcome Smith"
     When I save the current video as "login-flow.webm"
      And I stop video recording

That's the same login scenario from the Webship-JS "at a glance" example; the video steps just wrap around it. If Then I should see "Welcome Smith" fails, you don't need to ask the original author what "Smith" was supposed to look like, you open login-flow.webm and watch it happen.

The bigger picture: async triage

The real win isn't the recording itself; Playwright has supported recordVideo for years. It's that Webship-JS treats the recording lifecycle as something a test author controls from the same file where the scenario lives, instead of something a test infrastructure engineer configures globally and hopes covers the right cases. Combined with on-failure mode, that turns video from "nice to have if someone remembers to wire it up" into a default safety net for exactly the runs where it matters: the ones that broke, on a machine nobody in the room has access to, at 2 a.m. their time.

If you're already running Webship-JS, the video step group sits alongside the other 35 step groups, accessibility, network, REST, screenshots, and the rest, in the 2.0.x documentation.