Release evidence, not just green checks
SDODS runs BDD tests for UI and API flows and keeps the proof: a screenshot before and after every step, the requests behind it, and the history of every run. Anyone on the team can look at a release and say yes.
Free under the Apache-2.0 license.
When I login with "standard_user" and "{{standardPassword}}"auth/login.feature, step 2, passed
Before
After
Install in one line
Works on macOS, Linux and Windows. Node 22 is the only requirement.
curl -fsSL https://sdods.com/install.sh | shirm https://sdods.com/install.ps1 | iexWhat a run leaves behind
Confidence to ship is usually spread across a green pipeline, a manual check and a screenshot pasted into a ticket. SDODS keeps it in one place. Each scenario is tied to a business capability, each run can be repeated with one command, and each regression comes with the screenshots and requests that explain it.
This is a real run of the demo project.
What ships in the box
Write the tests
- UI, API and hybrid in one language
- Gherkin with one merged fixture set, so a scenario can seed data through the API and check the result in the browser.
- Data and user pools
- CSV, JSON, YAML, database tables and faker factories per environment. Each worker leases its own account and reuses its login state.
- MCP server and agents
- 86 tools for Claude Code, Codex, Cursor, VS Code, Gemini CLI and any MCP client, plus planner, generator, healer and upgrader agents.
Run them anywhere
- Many apps, many environments
- One YAML file per project and one per environment, with a precedence you can explain. Secrets only ever arrive through ${VAR}.
- Every browser you ship to
- Chromium, Edge, Firefox, WebKit and mobile emulation. --project-matrix runs them all, and lint checks every @skip:<browser>.
- CI, GitHub and Jira
- Check runs, PR comments, deduplicated issues and @jira:KEY links. Schedule runs from the server, crontab, systemd or Actions.
Keep the proof
- Before and after every step
- A screenshot either side of each UI step, request and response snapshots for API steps, and visual baselines chosen per suite tag.
- Locators that heal
- When a locator breaks, SDODS scores candidate replacements, records what it chose and proposes the fix to the page object.
- Run history that remembers
- Results in SQLite or Postgres show flaky scenarios, fragile locators, unstable environments and suite health over time.
How it works
Everything starts from the command line. The web UI, the MCP server and the scheduler run the same commands and stream their output, so CI needs nothing but Node and the repository.
sdods CLI
You, CI or the scheduler start a run.
Config and registry
Project and environment YAML resolve; steps load.
Browser and API runs
Playwright drives each scenario.
Evidence
NDJSON events and screenshots are written.
History
Results land in SQLite or Postgres.
Review
The web UI, MCP server and agents read it back.
Your first run
sdods init scaffolds a workspace with a demo project, so the first run needs nothing of yours.
sdods init ~/my-tests && cd ~/my-tests
sdods run -p demo-shop -e staging -l api
sdods run -p demo-shop -e staging -l ui -b chromium -t @smokeOptions, upgrade and uninstall are on the install page and in the installation guide.
Works with your AI coding tools
Claude Code, Codex, Cursor, VS Code, Gemini CLI, Windsurf and any MCP client. Install the plugin or the skills, then ask your assistant to plan, write, run, heal or review tests. Agents reuse your logged-in CLI session, so no API key is required.
A team can also share one SDODS server and connect every assistant to its /mcp endpoint with a scoped token. The AI coding tools guide covers each client.
Using an AI coding agent? Install SDODS:
Install the SDODS plugin in Claude Code: skills, subagents, commands and the MCP server.
/plugin marketplace add YarlisAISolutions/sdods-skills/plugin install sdods@sdods
Missing something you need?
Feature requests and feedback go straight to the maintainers by email. You do not need an account with us.