Add initial integration tests for @sentry/browser public API.

[onurtemizkan]

[Incomplete]

Resolves: #4261

cc: @AbhiPrasad, @rhcarvalho

The tests are not too deep, as per our discussion before, please point out the places that are ended up too shallow, so I'll extend them.

Tests for Sentry.flush and Sentry.showReportDialog are missing.

Two questions:

• Any suggestions on how to create a state that we guarantee that event queue stays unflushed until we call Sentry.flush()?

• What scenario would be good to test Sentry.showReportDialog? (Script injection / Existence of the iframe / Interactivity?)

[github-actions]

size-limit report

Path	Base Size (7f1fe2d)	Current Size	Change
@sentry/browser - CDN Bundle (gzipped)	20.35 KB	20.35 KB	+0.02% 🔺
@sentry/browser - CDN Bundle (minified)	64.99 KB	64.99 KB	+0.01% 🔺
@sentry/browser - Webpack	22.35 KB	22.35 KB	0%
@sentry/browser - Webpack - gzip = false	76.5 KB	76.5 KB	0%
@sentry/react - Webpack	22.38 KB	22.38 KB	0%
@sentry/nextjs Client - Webpack	46.49 KB	46.49 KB	0%
@sentry/browser + @sentry/tracing - CDN Bundle (gzipped)	28.51 KB	28.51 KB	+0.02% 🔺

[AbhiPrasad]

Maybe we forgo the Sentry.flush tests for now - there's an argument that they are only really useful in node environments.

For showReportDialog, I'd like to see the injectReportDialog tested

sentry-javascript/packages/browser/src/helpers.ts

Lines 203 to 215 in 940faf8

	const script = global.document.createElement('script');
	script.async = true;
	script.src = getReportDialogEndpoint(options.dsn, options);
	if (options.onLoad) {
	// eslint-disable-next-line @typescript-eslint/unbound-method
	script.onload = options.onLoad;
	}
	const injectionPoint = global.document.head || global.document.body;
	if (injectionPoint) {
	injectionPoint.appendChild(script);

to make sure we are adding the correct script attributes and correctly appending it onto the document.

[AbhiPrasad]

This is a good start Onur! To make it easier to review, could you split this PR up into different PRs per test suite? We can make as many branches as we want :)

[rhcarvalho]

there's an argument that they are only really useful in node environments.

@AbhiPrasad could you share some more context on this?

[rhcarvalho]

• Any suggestions on how to create a state that we guarantee that event queue stays unflushed until we call Sentry.flush()?

If you ever need this, IMHO the best way is to write a custom transport and use that transport to synchronize the behavior of the SDK with the test code.

[AbhiPrasad]

@AbhiPrasad could you share some more context on this?

There are currently no instances of us using flush internally in browser contexts. In addition, I can't recall us solving a user problem by recommending for them to use flush when they were facing that problem in a browser context (please correct me if I'm wrong).

IMO flush shouldn't even be public API for the browser env (close also), I think it doesn't provide that much value.

[rhcarvalho]

I can't recall us solving a user problem by recommending for them to use flush

I think this is simply due to no error event == no perceived problem. We have no visibility onto events that are not flushed out, but for browser that's on the end user interacting with the browser to decide, so...

IMO flush shouldn't even be public API for the browser env (close also), I think it doesn't provide that much value.

👍

... considering the lifetime of a page and the JS execution context, I agree that for the majority of cases flushing for browser apps can be handled exclusively by the SDK.

And to be clear, I also agree that we don't need to focus on flush tests right now.

I do see a case where flush/close would come in handy though, which is related to multi-hub/client usage and "Federated Modules" / "Micro-frontends" when the lifetime of certain page components is controlled by JavaScript code and the page itself lives longer than individual components (with their own transports). In that case, it might make sense to put flushing before unmounting components at the hand of SDK users (or we find a way to make it "just work").

[onurtemizkan]

Closing as this PR is replaced by separate PRs per API.