Use cases#
TestZeus plugs into your workflow four ways. They all talk to the same platform (https://prod.testzeus.app/api) — pick the one that fits what you’re doing, and mix them freely.
Which one should I use?#
pip install testzeus-cliA direct, scriptable handle on TestZeus — nothing to write, and it exits with a status code CI can gate on.
Reach for it when:
Quick one-off checks from your terminal
Shell scripts, Makefiles & cron jobs
Gating a deploy from a CI pipeline
Example: run a smoke suite in a GitHub Action and fail the build the moment a test goes red.
testzeus test-run-group execute-and-monitor \
--name "Smoke" --tags smoke
pip install testzeus-sdkA typed async client for when testing has to live inside your own product or service logic.
Reach for it when:
Embedding TestZeus into your app or backend
Custom automation & internal tools
Reading results to act on programmatically
Example: when a PR merges, your backend triggers a run and writes the pass/fail back to your own dashboard.
async with TestZeusClient() as c:
run = await c.test_run_groups \
.create_and_execute(name="ci", test_ids=ids)
Exposes TestZeus as native tools so a chat client can run and inspect tests right in the conversation.
Reach for it when:
You live in Claude Desktop or Cursor
Ad-hoc, conversational testing
No terminal or code in the loop
Example: ask Claude Desktop “run the login test and show me the failures” — it calls run_test and reports back.
claude mcp add testzeus -- testzeus-mcp-server
Plain-English playbooks a coding agent loads on demand to author and run whole suites hands-off.
Reach for it when:
Inside a coding agent (Claude Code, Codex)
Authoring tests from a description
End-to-end flows you don’t want to babysit
Example: “Create a checkout regression suite and run it in staging” — the agent writes the Gherkin and runs it.
# in your coding agent
"create a login test and run it in staging"
How they fit together#
The four surfaces are two layers over the same API:
Skills + MCP are the agent-facing layer — natural language in, tests run, results back.
CLI + SDK are the direct/programmatic layer — for a human in a terminal or code in an app.
Because they share one backend, you can combine them: author tests with skills, then gate deploys with the CLI in CI.
Common use cases#
I want to… |
Use |
|---|---|
Gate a deploy in CI |
CLI in your pipeline |
Author tests in plain English |
Skills in your coding agent |
Let Claude Desktop / Cursor drive testing |
MCP server |
Embed testing inside my own product |
Python SDK |