Sentry SDK captures unwanted events from the test suite in CI

By Kaveh Alemi·Latchkey

If Sentry is initialized with a live DSN during tests, every error the suite raises on purpose is captured and transmitted, polluting your Sentry project with noise and consuming quota. Tests should not send real events.

What this error means

After a CI run, your Sentry project fills with events whose stack traces point at test files or intentionally-thrown fixtures, and issue counts spike on every pipeline run.

Sentry event captured:
Error: simulated failure for test
  at Object.<anonymous> (test/payment.test.js:42:11)   # a test fixture, not prod

Common causes

A live DSN is set during tests

The same DSN used in production is present in CI, so captureException and unhandled-error hooks transmit to Sentry for every intentional test failure.

No environment gate around init

Sentry.init runs unconditionally, so the transport is active while the test runner exercises error paths.

How to fix it

Do not initialize Sentry in tests

1. Skip Sentry.init when running under the test environment.
2. Or init with no DSN so capture is a no-op.
3. If init is required, use beforeSend returning null to drop all events.

Sentry.init({
  dsn: process.env.SENTRY_DSN,
  enabled: process.env.NODE_ENV !== 'test',
});

Drop events with beforeSend in test config

Return null from beforeSend so nothing is transmitted even if init runs.

Sentry.init({ dsn, beforeSend: () => null });

How to prevent it

• Set enabled:false (or no DSN) for the test environment.
• Use beforeSend returning null as a safety net in tests.
• Keep a separate, non-production DSN for any environment that must send.

Frequently asked questions

Related guides

References

• GitHub Actions documentation