If you already have end-to-end tests, adding visual testing is a small change: install the Buddy plugin for your framework, call its snapshot command at the states you want to verify, and run your usual test command through the bdy CLI. Every run creates a session whose snapshots are compared against the approved baseline.
Shared prerequisites
These apply to all four frameworks, so the per-framework pages don't repeat them:
bdyCLI installed (requires Node.js v20+)- Suite token exported as
BUDDY_VT_TOKEN- copy it from the suite settings. In Buddy pipelines the token is injected automatically once the action is bound to a suite, so there is no variable to manage bdy tests visual setuprun once on the machine, to install the discovery browser that collects page resources after each snapshot
The four steps
- Install the visual tests plugin for your framework
- Register or instantiate it next to your existing runner setup
- Take snapshots inside your tests, at states the tests already reach
- Run the tests with
bdy tests visual session create "<your test command>"
The wrapping command is what turns an ordinary run into a session: it starts a local plugin server, runs your command unchanged, collects the snapshots the plugin reports, and uploads them. Your app can stay on localhost - nothing has to be publicly reachable. When the run finishes, the session appears in the suite with every snapshot rendered across the browsers and devices from the suite settings, and changed views wait for you in Reviewing & Approvals.
Because the render matrix lives in the suite and not in your test code, one snapshot call can produce many compared images - three browsers at two resolutions means six renders per call.
session create flags: --oneByOne sends snapshots progressively so you can start reviewing during long runs; --parallel + bdy tests visual session close let multiple runners contribute to a single session. See the CLI reference.
Which page do you need?
The plugins differ in how they get hold of the browser page, and that is what shapes the integration:
| Framework | Integration model | Snapshot call |
|---|---|---|
| Playwright | A fixture wrapping the test object | visualTestPlugin.takeSnap(page, name) |
| Selenium | A plugin object constructed around your WebDriver (Java, C#, JavaScript) | takeSnapshot(name) / TakeSnapshotAsync(name) / takeSnap(name) |
| Cypress | A custom command registered in the support file | cy.takeSnap(name) |
| Puppeteer | A plain import in a Node script, no runner involved | takeSnap(page, name) |
Two consequences worth knowing before you pick a page:
- Where the plugin holds the page for you (Cypress, Selenium), the snapshot call takes only a name. Where you own the page object (Playwright, Puppeteer), you pass it in - which also means you can snapshot a second tab or popup.
- Outside a session the snapshot call is a silent no-op, so your plain
npx cypress run,mvn test, ornode script.jskeeps working exactly as before. Selenium and Puppeteer expose this as asuppressErrorsargument.
Playwright
Add Buddy visual testing to your Playwright tests - install the plugin, take snapshots, and run sessions with the bdy CLI.
Selenium
Add Buddy visual testing to Selenium tests in Java, C#, or JavaScript - install the plugin, take snapshots, and run sessions with the bdy CLI.
Cypress
Add Buddy visual testing to your Cypress tests - install the plugin, take snapshots with cy.takeSnap, and run sessions with the bdy CLI.
Puppeteer
Add Buddy visual testing to your Puppeteer scripts - install the plugin, take snapshots, and run sessions with the bdy CLI.