A Failed CI Run Shouldn't Be Your First Clue Something's Misconfigured.
Before you wire TestSprite into CI, run testsprite doctor. It checks that your API key, network access, and CLI version are all correctly configured — so a dumb setup problem doesn't masquerade as a real test failure.
Built Into the Same CLI You Already Run
Verify Your API Key
testsprite doctor confirms your TESTSPRITE_API_KEY is set and valid before a CI job burns its first run on an authentication error.
Check Network & Proxy Access
Corporate proxies and locked-down CI runners can silently block outbound requests. Doctor confirms the CLI can actually reach TestSprite before you find out mid-pipeline.
Confirm Your CLI Version
A version mismatch between what's installed and what your pipeline expects can fail in ways that look like a product bug. Doctor flags it before it does.
Run It Anywhere
Same check whether you're setting up locally, wiring a new CI job, or debugging why a teammate's pipeline won't authenticate.
$ testsprite doctor Checking environment... ✓ API key found and valid ✓ Network access to TestSprite confirmed ✓ CLI version up to date → environment looks good, ready to run tests $ testsprite doctor Checking environment... ✗ TESTSPRITE_API_KEY not set ✗ Network request blocked — check proxy configuration → fix these before running testsprite test run
Don't Let CI Debug Your Config For You
A pipeline that fails before it even reaches your tests isn't testing anything — it's just failing loudly. Running testsprite doctor first turns "why did CI just fail" into a two-second answer.
Built for Wiring TestSprite Into CI
Run It Before You Wire Up CI
Add testsprite doctor as the first step in your pipeline — right after install, before testsprite setup and any real test run.
Pairs With testsprite setup
Use testsprite setup --from-env --yes --agent <name> to configure credentials non-interactively, then run doctor to confirm they actually work.
Free and Open Source
npm install -g @testsprite/testsprite-cli gets you the CLI. It's Apache-2.0 licensed, so there's nothing blocking a first check.
Machine-Readable Output
Pass --output json to get results in a format your pipeline can parse and act on automatically.
Trusted By Businesses Worldwide
"TestSprite offers rich test case generation, clear structure, and easy-to-read code. It also supports simple online debugging with the ability to quickly expand by generating new test cases."
"TestSprite's automation helps us reduce tons of manual work. The developers can easily catch and resolve bugs earlier in the development process."
FAQ
What does testsprite doctor actually check?
It checks that your API key is set and valid, that the CLI can reach TestSprite over your network — including through a proxy — and that your installed CLI version is up to date.
When should I run it?
Right after installing the CLI, and again as the first step in any new CI pipeline — before testsprite setup or a real test run, so a config problem fails fast instead of mid-pipeline.
How is this different from just running a test and seeing what breaks?
A failed test run caused by a missing API key or a blocked network request looks identical to a real product failure until you dig in. Doctor separates "your setup is broken" from "your product is broken" before you waste a run on the wrong one.
Does it work in CI, or only locally?
Both — it's the same command either way. Run it locally while you're setting up, then again as a CI step so a proxy or credential issue in the pipeline environment doesn't slip through.
What if it flags a problem?
It points you to what's wrong — a missing TESTSPRITE_API_KEY, a blocked network path, or an outdated CLI version — so you can fix that one thing instead of debugging a test run that never had a chance to start.