Record execution results

Use the CLI when you already have a JUnit XML or Mochawesome JSON file. Use the SDK when your integration records individual execution results itself.

Choose the right execution record

Start with a plan that includes and assigns your test cases. Identify the execution in the intended plan run and configuration. A repository case ID, plan case ID, and execution ID are different values.

The CLI can provide that context:

tc getTestPlan --project 123 --test-plan-id 456 \
  --test-plan-run-id 567 --output ./test-plan.json

Use the IDs from the intended run. Do not update an earlier execution simply because it relates to the same repository case.

Record a result with the SDK

record-result.ts

import { createConfiguration, ExecutedTestCasesApi } from '@testcollab/sdk';

const api = new ExecutedTestCasesApi(createConfiguration(process.env.TESTCOLLAB_TOKEN!));
const execution = await api.updateExecutedTestCase({
  id: 789, // The execution record ID, not the repository case ID.
  executedTestCasePayload: {
    project: 123,
    testPlan: 456,
    testPlanTestCase: 567,
    status: 'passed', // An active status system name in this project.
    comment: 'Checkout succeeded in the staging smoke test.',
    executionSource: 'ci',
    executionContext: {
      tool: 'checkout-smoke',
      provider: 'github-actions',
      runUrl: 'https://github.com/example/shop/actions/runs/123',
    },
  },
});

console.log('Updated execution:', execution.id);

Use an active status system name for your project. Custom status display labels are not necessarily their API system names; inspect the status vocabulary.

Preserve evidence and provenance

Keep the CI run URL in executionContext so a reader can trace the result to the pipeline. Use the attachment/upload methods when your integration manages evidence itself.

For file-based CI reporting, the CLI handles the reporting workflow and supports execution evidence. To report a single case with files, use tc reportCase with an exact execution ID and one or more --attachment paths.

Confirm the result

Read the execution again after an update if a downstream decision depends on its final state. Run a quality gate after all expected results have been published, rather than immediately after accepting background work.