Skip to content

Add a reporter that emits test-related Open Telemetry spans. #2087

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

atheriel
Copy link

@atheriel atheriel commented Jun 4, 2025

This commit introduces a variant of the Check reporter that records Open Telemetry traces for package tests. At present it records a parent span for each context/file and child spans for each test case.

Span attributes are drawn from the semantic conventions.

Here is what it looks like running a part of testthat's own test suite and sending traces to Logfire:

testthat in Logfire

It also makes some effort to work out the package's GitHub URL so that we can set VCS-related attributes. This is what allows the Open in GitHub button shown in Logfire to work:

Open in GitHub on Logfire

Note that this uses the existing session API from the otel package to allow parallel testing, but this API has known issues.

Basic unit tests are included.

This commit introduces a variant of the Check reporter that records Open
Telemetry traces for package tests. At present it records a parent span
for each context/file and child spans for each test case.

Span attributes are drawn from the semantic conventions [0].

It also makes some effort to work out the package's GitHub URL so that
we can set VCS-related attributes.

Note that this uses the existing session API from the `otel` package to
allow parallel testing, but this API has known issues.

Basic unit tests are included.

[0]: https://opentelemetry.io/docs/specs/semconv/registry/attributes/test/

Signed-off-by: Aaron Jacobs <aaron.jacobs@posit.co>
@gaborcsardi
Copy link
Member

Would it make sense to support telemetry in the already existing reporters?

@atheriel
Copy link
Author

atheriel commented Jun 5, 2025

Yeah, I think that's an alternative, but it might require deeper changes to the package to enable. Having a standalone reporter seemed like the least invasive route.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants