Report Automated Test Results from Any Framework

On this page

If your test framework can write JUnit XML, you can report its results to TestCollab. Cypress and other Mocha-based projects can also use Mochawesome JSON. Your framework still runs the tests; @testcollab/cli reads one result file and updates the matching executions in a TestCollab test plan.

For installation and authentication, start with TestCollab CLI: Install and First Run. The examples below use CLI version 1.17.0 and Node.js 18 or later.

The standard reporting path is tc createTestPlan, then your test runner, then tc report. Build recording, quality gates, agent workflows, and auto-create are optional extensions, not required upload steps.

Choose a result format

Format	Use it for	CLI option
JUnit XML	Most JavaScript, Python, Java, PHP, Ruby, Go, .NET, mobile, and browser test runners that provide a JUnit-compatible reporter	--format junit
Mochawesome JSON	Cypress and Mocha-based suites configured with Mochawesome	--format mochawesome

TestCollab does not read Playwright HTML, generic JSON, coverage reports, or console output as test results. Configure the runner to create one JUnit XML or Mochawesome JSON file, then pass that exact path to --result-file. The CLI does not expand globs or upload a directory. See JUnit XML Format Explained for a complete example.

The basic upload workflow

Create a plan from your CI-tagged cases, run the framework, and upload the file to that plan:

export TESTCOLLAB_TOKEN="your-token"

# 1. Create and assign the TestCollab plan
tc createTestPlan \
  --project 123 \
  --ci-tag-id 88 \
  --assignee-id 17
source tmp/tc_test_plan

# 2. Run the tests and generate a result file
pytest --junitxml=results.xml

# 3. Upload the result file
tc report \
  --project 123 \
  --test-plan-id "$TESTCOLLAB_TEST_PLAN_ID" \
  --format junit \
  --result-file ./results.xml

Replace 123, 88, and 17 with the project, CI tag, and assignee IDs. Use the API token owner's user ID as the assignee. Each result needs a case marker such as [TC-42], and that case must be part of the created plan.

This three-stage path is enough to upload results. You do not need tc createBuild unless you want build traceability, and you do not need tc gate unless your team deliberately uses the complete TestCollab plan as a separate CI policy decision.

tc report --auto-create is an optional shortcut that replaces createTestPlan. Do not add it as another step in the standard path.

Framework recipes

The following runners have a documented path to a compatible result file. Reporter packages and output paths can change between framework versions, so confirm that the file exists before calling tc report.

Framework	Generate a result file	File passed to TestCollab
Pytest	pytest --junitxml=results.xml	results.xml
Playwright	PLAYWRIGHT_JUNIT_OUTPUT_NAME=results.xml npx playwright test --reporter=junit	results.xml
Jest	Install jest-junit, then run JEST_JUNIT_OUTPUT_DIR=./reports npx jest --reporters=default --reporters=jest-junit	reports/junit.xml, or the filename configured for jest-junit
Cypress	Configure the mochawesome reporter with JSON enabled, then run npx cypress run	mochawesome-report/mochawesome.json
TestNG	mvn test	One file from test-output/junitreports/
JUnit 4 or 5	mvn test or gradle test	One file from target/surefire-reports/ or build/test-results/test/
Robot Framework	robot --xunit results.xml tests/	results.xml
PHPUnit	phpunit --log-junit results.xml	results.xml
Cucumber.js	Use @cucumber/junit-xml-formatter to write reports/results.xml	reports/results.xml
Cucumber JVM	Configure junit:target/cucumber-reports/results.xml	target/cucumber-reports/results.xml
WebdriverIO	Configure @wdio/junit-reporter with an output directory and filename	The configured JUnit XML file
TestCafe	npx testcafe chrome tests/ --reporter junit:results.xml	results.xml
Newman or Postman	npx newman run collection.json --reporters cli,junit --reporter-junit-export results.xml	results.xml
Behave	behave --junit --junit-directory ./reports	One generated file such as reports/TESTS-features.xml
Go	go test ./... -v 2>&1 | go-junit-report > results.xml	results.xml
Kaspresso or Kotlin	./gradlew connectedAndroidTest	One JUnit file from app/build/outputs/androidTest-results/

For detailed setup, see the dedicated guides for Jest, Playwright, and Cypress.

Other frameworks can work when their reporter produces compatible JUnit XML. Generate a small file first and confirm each <testcase> has a useful name or classname containing the TestCollab ID.

Map automated tests to TestCollab cases

For an existing plan, the result needs an explicit TestCollab case ID. The following forms are recognized case-insensitively:

[TC-42] customer can sign in
TC-42 customer can sign in
customer can sign in id-42
customer can sign in testcase-42

The bracketed [TC-42] form is recommended because it is visible and unambiguous. JUnit matching checks the test case name first and then classname. Mochawesome matching checks fullTitle first and then title.

A marker-free title is treated as an ID only when the entire title is a slug ending in digits, such as checkout-flow-42. Prose such as renders UTF-8 correctly or uses SHA-256 is not treated as case 8 or 256. An explicit marker always wins.

Report browser, OS, or data configurations

If an existing TestCollab plan has configurations, identify the configuration as well as the test case:

• For JUnit XML, include config-id-7, config-7, or [config-id-7] in the test case name or classname.
• For Mochawesome JSON, make every top-level suite a configuration suite named exactly config-id-7, using the applicable TestCollab configuration ID.

<testcase
  classname="Chrome config-id-7"
  name="[TC-42] customer can sign in"
/>

--auto-create does not create or route results into a multi-configuration plan. Prepare the configured plan first and report to it with --test-plan-id.

Make the CI result reliable

• Check the mapping summary. A valid report can finish with warnings for missing IDs, cases that are not in the plan, or executions that are not assigned to the token owner. An upload command reaching exit 0 does not mean every test was matched.
• Choose the CI verdict deliberately. Normally, preserve the test runner's exit status and use tc report only to upload its results. tc gate is an optional policy layer for teams that want the whole TestCollab plan, including manual or custom statuses, to decide whether CI proceeds.
• Handle multiple result files deliberately. Merge them with a framework-specific tool, or report each file separately. Do not use --skip-missing on each shard, because each shard would mark cases from the other shards as skipped.
• Keep the test step and upload step separate. Configure CI so the upload still runs after test assertions fail and the result file has been written.

Use the EU region

For an EU-hosted account, add the following option to every TestCollab CLI command. The CLI does not select a region automatically.

--api-url https://api-eu.testcollab.io

Troubleshooting

The CLI says the result file was not found

Confirm the reporter wrote a file rather than standard output, then pass the exact file path. For example, Playwright's JUnit reporter writes to standard output unless PLAYWRIGHT_JUNIT_OUTPUT_NAME or a configured outputFile is used.

The file parses, but no cases are updated

Inspect the generated JUnit name and classname, or the Mochawesome fullTitle and title. Confirm the [TC-42] value is a test case ID, the case is in the plan, and its execution is assigned to the API token owner.

Results go to the wrong configuration

Use the numeric TestCollab configuration ID, not its display order or browser name. For JUnit, put the marker in each test's name or classname. For Mochawesome, all top-level suites must follow the exact config-id-N convention.

Failed tests do not make tc report fail

This is expected. tc report records pass, fail, and skip statuses, while the test runner normally supplies the CI verdict. If your team instead wants the complete TestCollab plan to make a separate release decision, configure the optional TestCollab quality gate.