Problem
Several unit test specs use SentrySubsystem->InitializeWithSettings() to re-initialize the SDK mid-session in order to inject test handler classes (BeforeXXX handlers, trace samplers). This pattern has two problems:
- Instability: Re-initializing the subsystem during an editor automation test session can leave the SDK in a state where subsequent tests may fail or behave unpredictably.
- Shallow coverage: These tests only verify in-process behavior (handler gets called, receives correct data) but never check whether the data actually reaches Sentry correctly. A handler could modify attributes locally, pass all unit test assertions yet produce malformed data on the wire.
Proposed solution
Each unit test to which the above applies should be replaced with an integration test that exercises the full pipeline: sample app sends data → handler or sampler modifies it → data arrives at Sentry → test fetches it via the API and performs assertions.
This was partially addressed in #1224 where such log-related unit tests were replaced with proper e2e integration tests. The same approach should be applied to the remaining specs.
Affected test files
File: SentryBeforeMetricHandler.spec.cpp
What it tests: BeforeMetricHandler is called when a metric is emitted; verifies metric name and type
File: SentryBeforeLogHandler.spec.cpp
What it tests: BeforeLogHandler is called when a log is emitted; verifies log message, level and attributes
File: SentryTraceSampling.spec.cpp
What it tests: Trace sampler callback receives correct SamplingContext with transaction name, operation, and custom data
File: SentryScope.spec.cpp ("Scope params" describe block)
What it tests: Scope parameters (level, fingerprint, tags, extras, context) are applied to a captured event
File: SentrySubsystem.spec.cpp
What it tests: General subsystem functionality (capture message/event, transactions)
Related items
Problem
Several unit test specs use
SentrySubsystem->InitializeWithSettings()to re-initialize the SDK mid-session in order to inject test handler classes (BeforeXXXhandlers, trace samplers). This pattern has two problems:Proposed solution
Each unit test to which the above applies should be replaced with an integration test that exercises the full pipeline: sample app sends data → handler or sampler modifies it → data arrives at Sentry → test fetches it via the API and performs assertions.
This was partially addressed in #1224 where such log-related unit tests were replaced with proper e2e integration tests. The same approach should be applied to the remaining specs.
Affected test files
File:
SentryBeforeMetricHandler.spec.cppWhat it tests: BeforeMetricHandler is called when a metric is emitted; verifies metric name and type
File:
SentryBeforeLogHandler.spec.cppWhat it tests: BeforeLogHandler is called when a log is emitted; verifies log message, level and attributes
File:
SentryTraceSampling.spec.cppWhat it tests: Trace sampler callback receives correct SamplingContext with transaction name, operation, and custom data
File:
SentryScope.spec.cpp("Scope params" describe block)What it tests: Scope parameters (level, fingerprint, tags, extras, context) are applied to a captured event
File:
SentrySubsystem.spec.cppWhat it tests: General subsystem functionality (capture message/event, transactions)
Related items