Puppetry: a codeless Puppeteer test recorder its author has deprecated

A desktop recorder that ends in a Jest bundle

Puppetry is a desktop application for creating end-to-end browser tests without writing test code. It sits on top of Puppeteer for browser control and Jest as the runner underneath, and the README positions it for developers, QA engineers and testers, with the explicit claim that it can be used by QA engineers with no programming background. The UI offers a predefined list of browser methods and assertions with predefined settings. From that list the workflow is: record a user flow, declare element targets as pairs of the form variable equals locator, where the locator is either a CSS selector or an XPath, run the suite in Chromium, Chrome, Firefox or Edge, and export the project as a Jest and Puppeteer bundle ready to run from the command line, for example by a continuous integration server. The last point is the one that separates Puppetry from a simple macro recorder. The application is a front end to a JavaScript test suite rather than the place where the tests live.

Project, suite, test context and test case

Test structure in Puppetry follows a BDD shape, and the README names the four levels: project, suite, test context, test case. That hierarchy is what the recorder writes into and what the exporter reads out. Around it sit the features that make the tool more than a click recorder. There is a built-in automation recorder, an interactive mode in which a person steps through test steps in a way the README compares to Cypress, staging with template variables and expressions, reusable and configurable test scenarios kept as snippets, and version control integration for the project files. Reporting runs through Allure test reports. The listed testing types are unusually wide for a recorder: functional testing, testing of dynamic content, exhaustive testing, performance testing, visual regression testing, mocking of HTTP and HTTPS requests, REST API testing, testing of Google Analytics tracking code, testing of Chrome extensions, testing of Shadow DOM and testing of transactional emails. Each of those is a separate page in the documentation, and each is a claim the README makes about what the exported bundle can do.

Snap on Linux, a cask on macOS, and a narrow Node range

Installers for each platform are published on the repository releases page. The README lists the supported systems as Windows 7 and greater at 64 bit, Ubuntu 14.04 and greater at 64 bit, and MacOS X 10.10 (Yosemite) and greater at 64 bit. Linux users install from Snapcraft, and macOS users install from Homebrew. On Linux can be installed with Snapcraft:

sudo snap install puppetry

On Mac can be installed with Homebrew:

brew cask install puppetry

The engineering detail that matters more for a CI setup is in package.json rather than the README. The engines field asks for node >=14 <15, a deliberately narrow window that excludes every Node release after 14. The application itself is an Electron package, built with webpack and packaged by electron-builder, with separate scripts for Linux snap, Windows appx and macOS targets. Anyone planning to run the source tree alongside a modern Node toolchain will hit that engines constraint before anything else.

Element targets as named variables, assertions from a fixed list

The core idea of a recording tool is that it captures what a person did and can replay it. Puppetry's mechanism for keeping that replay stable is the element target declaration, a pair of a variable name and a locator that is either a CSS selector or an XPath. Declaring targets separately from the recorded steps means the locator is the thing you edit when a page changes, rather than rewriting a flow. Assertions come from the predefined list in the UI, with predefined settings and guided tips, so a recorded scenario does not carry hand-written code for the check itself. The interactive mode supports the same idea in reverse: a person steps through a flow while the tool states what it would record. The recorder and the interactive mode are documented as separate features, and the README links to distinct pages for them, which suggests two entry points into the same underlying suite structure.

Two export shapes, one for CI and one for people

Puppetry exports in two formats, and the difference matters for how a team uses the tool. The first is a Jest.js project, which the README describes as ready to plug into a CI/CD pipeline, with the Puppeteer driver underneath it. The second is a human-readable test specification, provided with screenshots per test step, which is meant for people rather than a runner. That second format is unusual for a test tool and suggests the author expected the output to be reviewed by stakeholders, not only executed by a server. The CI-facing export is what makes the tool compatible with an existing pipeline: you build suites in the desktop app, then hand a normal JavaScript project to the server, where it runs the same way as any other Jest suite. The repository itself keeps a jest-pkg directory, a jest.cfg.e2e.js, a jest.cfg.unit.js and a jest.setup.js at the top level, alongside a project-demo and a project-test directory and a start:project-test script that boots a local server for the examples.

The deprecation notice and the gap between push and release

The top of the README carries a notice titled Project Deprecated. In it the author explains that after watching the market for years since the last update, he has decided to officially deprecate Puppetry, that Playwright has evolved to cover almost everything he originally aimed to achieve and does it much better, and that the idea of codeless end-to-end testing, while exciting at the time, has proven to be a technological dead end. He also notes that AI-assisted development now allows end-to-end tests to be created by narrating what you want, which goes beyond the original Puppetry vision, and keeps the repository available as an example and a part of the project's history. The dates bear this out. The latest release is v3.2.6 from 2021-08-16, preceded by v3.2.5 in 2021 and v3.2.4 in 2020, while the last push to the repository was on 2026-06-19. Newer commits than the last release, but no new release for five years.

Where Puppetry is the wrong choice

There are clear situations where starting here is a mistake. The first is any new project, because the author has publicly declared the design goal obsolete and points at a different tool. The second is a team on a current Node runtime: the engines field restricts the source tree to node >=14 <15, and the desktop installers pin the same era of Puppeteer and Electron underneath. The third is a team that needs a maintained issue tracker, security fixes for the bundled browser driver, or a dependency path that tracks modern Chromium releases. A fourth case is a workflow that depends on the codeless premise, where someone on the team will not write a test file even once: the export path assumes the project owner is comfortable reading Jest output and debugging a Puppeteer stack, so the recorder saves typing rather than saving the need for code literacy. The licence situation is simpler than the engineering one. The licence field on the repository says MIT, so existing users keep the same permissive terms whatever they decide to do next.

Editorial conclusion

Teams already running a Puppetry project should keep it on the current MIT licence terms and plan a move rather than start something new, while anyone evaluating a fresh no-code recorder should look at Playwright instead, since the author calls the codeless approach a dead end and ships no release newer than v3.2.6 from 2021-08-16. Before adopting anything here, check the Node range in package.json against your own runtime, the engines field asks for node >=14 <15, and confirm that the exported Jest bundle still runs on the Puppeteer version your project resolves today.

Frequently asked questions

Official sources

1. dsheiko/puppetry on GitHub
2. License: MIT
3. Project website
4. README
5. Releases