New: TestSprite CLI is Now Live!

Your CI Already Knows How to Read This.

TestSprite test results can be exported in JUnit XML — the format most CI systems already know how to parse and display. No separate viewer, no new dashboard to check: results show up next to every other test suite your pipeline runs.

Built for the CI Dashboards You Already Check

JenkinsGitLab CICircleCIGitHub Actions
A test result nobody opens might as well not exist. Put it where the team is already looking, instead of asking them to open one more tab.

Speaks a Format CI Already Understands

JUnit XML is the format most CI test-report steps already parse, regardless of what language or framework produced it. There's no custom parser to write for TestSprite's output specifically.

Shows Up Where the Team Already Looks

Jenkins, GitLab CI, CircleCI, and GitHub Actions test-report widgets can render TestSprite results in the same run summary as every other test suite in your pipeline.

No Separate Viewer to Check

Instead of logging into another tool to see what passed, pass/fail counts and failure detail land in the CI run your team already opens after every build.

Pairs With Machine-Readable Output

Use the JUnit export for CI dashboards, or reach for --output json when a script needs to act on results programmatically instead.

# .github/workflows/test.yml
- name: Run TestSprite tests
  run: testsprite test run TC_checkout_promo
  env:
    TESTSPRITE_API_KEY: ${{ secrets.TESTSPRITE_API_KEY }}

- name: Publish test report
  uses: dorny/test-reporter@v1
  if: always()
  with:
    name: TestSprite Results
    path: 'testsprite-results.xml'
    reporter: java-junit

Stop Asking the Team to Check a Second Dashboard

A test result that lives somewhere your team doesn't already look tends to get ignored. Exporting to JUnit XML means TestSprite's pass/fail output lands in the same CI run summary as everything else, instead of asking anyone to context-switch.

Built for Pipelines You Already Have

Works With What You Have

Any CI system that supports JUnit XML — which is most of them — can render TestSprite output without extra tooling or a custom integration.

Fits Into an Existing Step

Add TestSprite as another test step in a pipeline that already runs unit and integration tests, and its report shows up in the same run summary.

Free Community Version

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

Preview Before You Wire It In

Use --dry-run to see what a run would do before it's part of a pipeline that runs on every commit.

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 is JUnit XML, and why does CI care about it?

It's a long-standing XML schema for reporting test results that originated with the JUnit framework but is now parsed by most CI systems regardless of what language or framework actually produced the results.

Do I need a plugin to see TestSprite results in my CI dashboard?

No — Jenkins, GitLab CI, CircleCI, and GitHub Actions test-report widgets already know how to parse JUnit XML, so TestSprite's export slots into whatever test-report step you already have configured.

Does JUnit export replace the CLI's other output formats?

No — it sits alongside --output json for machine-readable output and the normal terminal output. Use whichever format fits the tool that's reading it.

Does this work for both frontend and backend test runs?

Yes — the export applies to results regardless of whether they came from browser-based frontend runs or backend/API runs.

Can I see what a run would do before wiring it into CI?

Yes — --dry-run previews a run without executing it, which is useful the first time you're adding TestSprite to a pipeline.

Stop Checking Two Dashboards.