New: TestSprite CLI is Now Live!

Some Test Plans Are Broken Before They Ever Run.

A malformed step or an undefined selector doesn't fail cleanly — it wastes a run figuring that out. testsprite test lint <planFile> checks a test plan's structure first, so you catch the problem before you spend time or credits on it.

Built Into the Same CLI You Already Run

GitHub ActionsGitLab CILocal runsAgent loops
A test plan that won't run isn't automatically a problem with your product — it might just be a malformed step. Lint the plan, don't debug it blind.

Catch Malformed Steps

testsprite test lint <planFile> checks every action and assertion step in a test plan for structural problems — before any of them run against your live environment.

Flag Ambiguous Assertions

An assertion without a clear target is a problem you don't want to discover mid-run. Lint catches it while the plan is still just a JSON file.

Spot Missing Selectors

A step that references a selector never defined in the plan gets flagged immediately, instead of surfacing later as a confusing failure.

Works on Any Test Plan

Lint runs on any test-plan JSON file — generated by TestSprite or edited by hand — so it fits into however your plans actually get created.

$ testsprite test lint test-plan.json
  Checking test-plan.json for structural problems...
  ✗ 2 issues found
    - step 3: assertion is missing a clear target
    - step 7: selector not defined in this plan
  → fix these before running the plan

$ testsprite test lint test-plan.json
  Checking test-plan.json for structural problems...
  ✓ no structural problems found

Don't Spend a Run on a Plan That Was Never Going to Work

A test plan with a malformed step or an undefined selector doesn't fail because your product is broken — it fails because the plan itself has a structural problem. Linting catches that upfront, before it costs you a run.

Built for Test Plans That Get Edited by Hand

Works on Any Test Plan

Generated, edited, doesn't matter — test lint runs on any test-plan JSON file in your project.

Feeds Back Into the Loop

An agent generating or editing a test plan can call test lint before handing it off to test run, catching problems while they're still cheap to fix.

Free Community Version

Offers a free community version, making us accessible to everyone.

Pairs With Running

Run testsprite test lint right before testsprite test run so a structural problem never gets the chance to burn a real run.

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 test lint actually check?

It checks a test-plan JSON file's structure — things like malformed action or assertion steps, assertions without a clear target, and selectors referenced but never defined — before the plan runs against your live environment.

How is this different from just running the test plan and seeing what happens?

Running the plan spends time and credits finding out the plan itself was broken. Linting finds the same structural problems from the JSON file alone, before anything executes.

Does this work on test plans I wrote or edited by hand, not just generated ones?

Yes — test lint runs on any test-plan JSON file, whether it came from TestSprite or was edited directly.

What do I do when test lint finds a problem?

Fix the flagged step in the test-plan JSON file and lint it again. A clean pass means the plan is structurally sound before you spend a run on it.

Should I run test lint every time, even on plans I've run before?

It's cheap to run and catches problems introduced by hand edits, so running it before test run is a reasonable habit — especially in CI.

Check the Structure Before You Spend the Run.