colcon-tesults test reporting
colcon is the build and test orchestration tool used in ROS 2. colcon-tesults is a colcon event handler that reads JUnit XML output after colcon test completes and uploads results to Tesults — with no changes to your test code or per-package configuration.
Recommendation
colcon-tesults provides basic pass/fail results from JUnit XML. If you are using GoogleTest (C++) or pytest (Python) we strongly recommend using gtest-tesults or pytest-tesults instead — they provide per-test descriptions, steps, custom fields, and file uploads. colcon-tesults is best suited for mixed workspaces or as a quick zero-config starting point.
Installation
Install colcon-tesults in the same Python environment as colcon:
pip install colcon-tesults
If you are using Pixi/RoboStack:
pixi add --pypi colcon-tesults
Configuration
Set TESULTS_TARGET to your target token and run colcon test as usual. colcon-tesults is active as soon as it is installed — no flags or per-package setup needed.
TESULTS_TARGET=token colcon test
Basic configuration complete
That's it. colcon-tesults collects JUnit XML from all packages after testing completes and uploads everything in a single request. If TESULTS_TARGET is not set, nothing happens and your tests run as normal.
Config file (optional)
Keep tokens out of scripts by using a key name and pointing to a config file:
TESULTS_TARGET=my-target TESULTS_CONFIG=/path/to/tesults.cfg colcon testtesults.cfg
# Tesults target tokens
my-target = eyJ0eXAiOiJ...
staging = eyJ0eXAiOiK...
Disable for a single run
colcon test --event-handlers tesults-
Build
TESULTS_BUILD_NAMEOptionalUse this to report a build version or name for reporting purposes.
TESULTS_BUILD_NAME=1.0.0 colcon test
TESULTS_BUILD_RESULTOptionalUse this to report the build result, must be one of [pass, fail, unknown].
TESULTS_BUILD_RESULT=pass colcon test
TESULTS_BUILD_DESCRIPTIONOptionalUse this to report a build description for reporting purposes.
TESULTS_BUILD_DESCRIPTION="Release build" colcon test
TESULTS_BUILD_REASONOptionalUse this to report a build failure reason.
TESULTS_BUILD_REASON="build error in package foo" colcon test
Result Interpretation
Result interpretation is not currently supported by this integration. If you are interested in support please contact help@tesults.com.
Go to the Configuration menu.
Select Build Consolidation.
When executing multiple test runs in parallel or serially for the same build or release, results are submitted to Tesults separately and multiple test runs are generated on Tesults. This is because the default behavior on Tesults is to treat each results submission as a separate test run.
This behavior can be changed from the configuration menu.
Build Consolidation
Click 'Build Consolidation' from the Configuration menu to enable and disable consolidation for a project or by target.
When build consolidation is enabled multiple test runs submitted at different times, with the same build name, will be consolidated into a single test run by Tesults automatically.
This is useful for test frameworks that run batches of test cases in parallel. If you do not have a build name to use for consolidation, consider using a timestamp set at the time the test run starts.
Build Replacement
When build consolidation is enabled, an additional option, build replacement can optionally be enabled too. Just as with build consolidation, when multiple test runs are submitted with the same build name the results are consolidated, but with replacement enabled, if there are test cases with the same suite and name received multiple times, the last received test case replaces an existing test case with the same suite and name. This may be useful to enable in situations where test cases are re-run frequently and you do not want new test cases to be appended and instead want them to replace older test cases. This option is generally best left disabled, unless test cases are often re-run for the same build and you are only interested in the latest result for the run.
Dynamically created test cases
If you dynamically create test cases, such as test cases with variable values, we recommend that the test suite and test case names themselves be static. Provide the variable data information in the test case description or other custom fields but try to keep the test suite and test name static. If you change your test suite or test name on every test run you will not benefit from a range of features Tesults has to offer including test case failure assignment and historical results analysis. You need not make your tests any less dynamic, variable values can still be reported within test case details.
Proxy servers
Does your corporate/office network run behind a proxy server? Contact us and we will supply you with a custom API Library for this case. Without this results will fail to upload to Tesults.