Sentry SDK initializes without a DSN but capture calls do not deliver events

Goal

Choose a safe way to exercise Sentry SDK delivery wiring in tests without a production DSN or outbound access to Sentry.

Constraints

When no usable DSN is supplied, many Sentry SDKs initialize successfully but treat capture as a no-op, so a passing test does not prove event delivery. The exact path depends on SDK major and runtime, and defaults for enabled, sampling, transport retries, and shutdown flush timeouts change between versions. A malformed DSN is not equivalent to a missing DSN in every SDK.

One option is to provide a syntactically valid but non-routable DSN so serialization, beforeSend, sampling, and transport construction remain active. The other is to omit the DSN or set enabled to false, which avoids network attempts but leaves those paths unexercised. A non-routable target may still trigger queuing, retries, background network attempts, or delayed shutdown behavior.

Questions

• For a pinned SDK version, does a missing DSN disable transport construction before capture is called?
• Does a non-routable DSN keep beforeSend and transport paths active without risking outbound test traffic?
• Which observable SDK state should tests assert to distinguish real delivery wiring from a silent no-op client?