Description
Description
Important
This is currently on hold as it is not a focus topic for the SIG - do NOT open PRs. This issue will be updated once it has been prioritized by maintainers.
We currently lack information on how to properly test apps/libraries that use OpenTelemetry JS. As OTel JS matures, we should add testing guidelines so that our users can avoid pitfalls when testing their apps/libraries that generate telemetry using OTel.
This issue is considered done when
- a doc has been added that describes how to properly unit test when using OTel JS
- a doc has been added that describes how to properly integration test when using OTel JS
- a doc has been added that describes how to properly E2E test when using OTel JS
Initial Thoughts
For application/library authors, I think it makes sense to test telemetry generation by mocking/spying on the @opentelemetry/api in unit tests. The reason for that is that `@opentelemetry/sdk-*" may receive more breaking changes then the API. So even if a new major version of the SDK is released you won't have to update all your tests, which will save you headaches in the long run.
The reason for the SDK and API being separate packages is that if something in the SDK gets a breaking change in a major version, users won't have to update their instrumentation code which only uses the API, and which may be mixed in with business logic - they just have to switch out the SDK setup code (which should be a just single file in their project). If the unit tests largely depend on the SDK anyway (via InMemory*Exporter and the data-model exposed by it) - then that would hold the update to the next major version back more than it needs to.
For integration tests, though - I think it absolutely makes sense to test output with an InMemory*Exporter from the SDK.
For E2E tests, I'd say the full SDK setup with the same exporter you'd use in prod is the best choice.
This will give users the most amount of coverage, while minimizing the impact of possible breaking changes in new major versions of the SDK.