Spearmint: a desktop app that writes your Jest tests from a form
Testing, simplified. || An inclusive, accessibility-first GUI for generating clean, semantic Javascript tests in only a few clicks of a button.
At a glance
- What is it?
- Spearmint is an Electron application for generating functional test files without writing code, covering accessibility, endpoint, GraphQL, Puppeteer, React, Hooks, Redux, Svelte, Vue, Security, and Solid.js. You pick a framework, fill in dropdowns, and the app emits Jest test code that uses the DOM query selectors from @testing-library.
- Who is it for?
- Adopt Spearmint if your team writes lots of shallow, repetitive Jest tests and wants a form instead of a template, or if accessibility and security checks are under-served in your suite. Do not adopt it for behaviour-heavy tests, since a generated test cannot express intent that the form has no field for.
- Can I use it commercially?
- Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 91 days ago.
- What is it written in?
- Mainly TypeScript, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on October 22, 2026, and from our analysis. They are not legal advice.
Editorial analysis
A form that compiles to Jest
Spearmint is described as testing, simplified, and as an inclusive, accessibility-first GUI for generating clean, semantic Javascript tests in only a few clicks of a button. The description of what it does is unusually concrete: it helps developers easily create functional Accessibility, Endpoint, GraphQL, Puppeteer, React, Hooks, Redux, Svelte, Vue, Security, and Solid.js tests without writing any code, and it dynamically converts user inputs into executable Jest test code by using DOM query selectors provided by @testing-library.
So the core mechanism is a translation layer from structured choices to source code. That is a different proposition from a code generator that scans your components and emits tests, and a different one again from a recording tool. There is no analysis of the codebase. You tell the application what the test should assert, and it writes the file.
The frameworks in that list explain the shape of the input. React, Vue, Svelte, and Solid share a shape of test, so the same arrangement, action, and assertion structure works for all of them. Redux has a different one, with reducer, action creator, asynchronous action creator, and middleware test statements. And hooks, context, endpoint, and GraphQL each have their own. Accessibility, Puppeteer, and security are the ones that are not framework-bound at all.
The application is MIT licensed, written in TypeScript, and the home page is spearmintjs.com. The last push to the repository was on 2026-07-23, but the published releases are older, with v0.14.0 from 2023-05-17, v0.11.0 from 2022-06-16, and v0.10.0 from 2022-04-28, so the repository has kept moving while the last tagged version stayed where it is. The README itself refers to Spearmint v14 in the banner, and there is a document in the repository titled Notes On Spearmintv15.md, which suggests the next version is in preparation.
The five step workflow
How it works section describes the flow precisely enough to follow.
You open the folder of the repository you would like to create tests for, then choose the framework or type of test you would like to create. The next step is to use the auto-complete, drop-down options, and tooltips features to easily create arrangement, action, and assertion test statements for React, Vue, Svelte, and Solid, reducer, action creator, asynchronous action creator, and middleware test statements for Redux, and hooks, context, endpoint, and GraphQL test statements.
Spearmint then converts your input to dynamically generate a test file in the Code Editor. You then follow the instructions in the recently added User Guide tab on the right to export and run your tests.
And there is a fifth step that is easy to miss and that the documentation bothers to spell out. You have to select your test file from the left panel in order to manually edit the test in the Test Editor, otherwise the changes will not be reflected in the test file.
That last point is the real shape of the tool. It is not a one-shot generator. It is a three-pane editor where the left panel lists the files, the middle is a form, and the right is the generated code, and the files you edit manually have to be re-selected before the editor will write to them. The generated test is a starting point you then edit, and the application is careful to tell you that the two directions of editing are not symmetric.
The arrangement, action, assertion structure is the classic test shape, and mapping it onto a form is what makes the tool usable by someone who does not want to remember the API of a testing library.
The Electron app, and the build scripts
The application is an Electron app, and the package manifest shows the shape of it.
"test": "NODE_ENV=test jest",
"start": "electron-forge start",
"start-dev": "concurrently \"electron .\" \"nodemon server/server.js\"",
"watch": "webpack --config webpack.config.ts --watch",
"package": "electron-forge package",
"make": "electron-forge make",
"dev": "npm run watch & npm run start-dev",
"rebuild": "electron-rebuild -f -w node-pty",
"docker": "electron . --no-sandbox",
"mac:installer": "electron-builder --mac",
"win:installer": "electron-builder --win",
"linux:installer": "electron-builder --linux",
"postinstall": "electron-builder install-app-deps"There is a local server in the picture. The start-dev script runs the Electron app and a nodemon process watching server/server.js at the same time, and the dev script combines the webpack watch with that, so a change to the front end rebuilds and reloads while the server restarts on its own. There is a server/ directory at the top level and a .env file, which is what makes that possible.
The electron-rebuild script for node-pty is the interesting one, and node-pty does not appear anywhere else in the description. It is a native module, so it has to be compiled against the Electron ABI rather than the system Node ABI, and electron-rebuild with -f and -w node-pty is the standard way to do that. The postinstall script runs electron-builder install-app-deps, which does the same job for every native dependency in the project.
The build configuration targets a mac universal binary with hardened runtime on, a Windows build, and a Linux deb. The main entry point is public/electron.jsx, and the app id and product name are both spearmint. The repository also carries a Dockerfile, a jest.config.js, a webpack.config.ts, and a server directory, so the whole thing is a conventional Electron project with a React and Express front end and back end.
The accessibility angle, and the bugs that undercut it
The repository is under the open-source-labs organisation, and the accessibility-first framing in the description is a real part of the project rather than a slogan. Accessibility is the first item in the list of test types, and there is a corresponding bug list that includes two accessibility entries.
The known bugs are worth reading closely, because they describe the tool honestly. The screen reader for Accessibility can turn on and off but does not read. And text to speech is not functioning properly under Accessibility. A third entry notes that some elements of draggable remain in Redux test case components.
The first two are in the category the tool is supposed to be best at. A generator for accessibility tests that ships with a non-functioning screen reader is a contradiction that a user will hit in the first ten minutes, and the mitigation is to use the generated accessibility test as a starting point and run it through a real checker rather than trusting the GUI preview.
The third entry is a different kind of problem. It says that some draggable elements remain in the Redux test case components, which points at the drag and drop feature in the Redux flow leaving stray DOM behind. The iteration roadmap addresses this directly, listing consider implementing React Dev Tools or react-dnd to restore the drag-drop functionality, and separately noting that some test cases need improvement on UI as they do not have any styling or optimal user experience.
The roadmap in general is candid about the state of the project. Persistent data is listed as unimplemented, with the note that a framework for login, including GitHub and Google, is not implemented even though a framework exists. Exporting test files as TypeScript is listed as a to-do, since the only export option is currently vanilla Javascript. And the dependency maintenance section notes the plan to consider removing MUI and switching to another component library or redoing the styling in CSS, in order to update the program to React 18+, because MUI is incompatible and seems not to be actively updating.
What version 0.14.0 changed, and the Docker path
The release notes for version 0.14.0 list five changes. Increased Typescript coverage, so Spearmint is now majority Typescript. Greatly bolstered internal testing on the program and instituted testing coverage reports for completeness visibility. Updated to the latest version of electron. Updated a variety of dependencies and libraries. And added documentation for future developers.
The TypeScript migration is the through-line of the roadmap as well, where the first item is continuing the TypeScript conversion to help with the maintainability and readability of the code and to move closer to 100% coverage. Two more items in the roadmap are about the same subject, namely continuing to extend internal testing coverage, with the note that a far greater amount of the application is tested now than it was previously but that there is more work to do.
There is a third item in the roadmap about adding more testing, and it is the most honest statement in the document. Deeper testing of existing frameworks should probably be the main priority, as many frameworks are implemented already but could use more fleshed out features. Adding additional frameworks is a possibility if there is a strong case for them, but adding more robustness to the current test suites is probably more important.
That is the right priority and it is worth taking at face value, because the failure mode of a test generator is generating a lot of shallow tests. The tool's own roadmap admits that breadth of frameworks has outpaced depth in the ones it supports.
There is also a container path. A commented-out section of the README describes Spearmint as available as an OCI-compliant container image via Docker, with Windows and Linux users able to run it from a Docker image pulled from Docker Hub, and the Dockerfile at the repository root is the corresponding build. The image is based on node:16.13 and installs the set of shared libraries an Electron app needs on Linux, including the X11 and GTK dependencies, and it runs as root deliberately, with a comment explaining that Electron needs root for its sandboxing.
Editorial conclusion
Adopt Spearmint if your team writes lots of shallow, repetitive Jest tests and wants a form instead of a template, or if accessibility and security checks are under-served in your suite. Do not adopt it for behaviour-heavy tests, since a generated test cannot express intent that the form has no field for. Verify first that the version you download matches the frameworks you use, since the last published release is v0.14.0 from May 2023 while the repository itself has continued to move.
Frequently asked questions
What does Spearmint generate?
It generates executable Jest test code from your input, using DOM query selectors provided by @testing-library. The test types are Accessibility, Endpoint, GraphQL, Puppeteer, React, Hooks, Redux, Svelte, Vue, Security, and Solid.js, and you choose a framework or test type, fill in the arrangement, action, and assertion fields, and the app writes the test file.
How do I install Spearmint?
Download it from the project website at spearmintjs.com. The documentation also describes a development mode setup, and the repository carries a Dockerfile for running it as a container image built on node:16.13.
What known bugs does Spearmint have?
The screen reader for Accessibility can turn on and off but does not read, and text to speech is not functioning properly under Accessibility. A third entry notes that some elements of draggable remain in the Redux test case components.
Can Spearmint export tests as TypeScript?
Not yet. The iteration roadmap lists add functionality for exporting test files as Typescript as a to-do item, and notes that currently the only export option is vanilla Javascript.
What is the latest published version of Spearmint?
v0.14.0, published on 2023-05-17, with v0.11.0 in June 2022 and v0.10.0 in April 2022 before it. The last push to the repository was on 2026-07-23, so the source has continued to move since that release.
Official sources
Add this badge to your README
If you maintain this project, the badge below links readers to this analysis and shows its maintenance status from the daily GitHub snapshot. Paste the markdown into your README; add ?metric=license or ?metric=stars to the image URL for a different field.
[](https://hysenlabs.com/projects/open-source-labs-spearmint)Was this useful?