feat: disable html reporter entirely for headless CI
Closed this issue · 5 comments
memory growth over time for the html reporter still occurs even when hidepassed is true as the hidden DOM nodes are retained. For test suites with massive quantities of tests this can have a significant effect.
@runspired Can you try removing the <div id="qunit"> element? That should effectively disable the HTML Reporter. I'm hoping in QUnit 3 to offer a configuration option like QUnit.config.reporters where you could explicitly add/replace the reporter, e.g. using HTML+TAP, or TAP only when using a CI listener/aggregator.
I ended up using pnpm patch to rewrite a small bit to enable this. Can put up a PR with that if you're interested, more just to see than to push forward.
@runspired Are you using an additional package for this? The HTML Reporter element is populated, but not created, by QUnit. It is typically declared in your test.html file, or equivalent as generated by a higher-level test runner (like karma-qunit).
As mentioned, we'll make this easier in the next release, but I'm checking to make sure I understand what you needed to patch and whether there's a way I can document today that doesn't involve a patch.
We're using it with testem and ember. The same html file gets re-used in both CI and browser. We could potentially find a way to juggle the launch file, but it's a bit hefty and I think the easier lift for us is going to be to either upstream the ability to disable it (as we've found this useful even in-browser for memory-leak testing) or to continue patching (it's a fairly tiny patch).
@runspired If we introduced an option like QUnit.config.reporters.html = false;, would that work? You'd need to set it very early on, and in a way where it will only apply when Testem is running automatically and not when serving the HTML file for debugging. Would you likely want to set this by default within ember-qunit?
When using Testem standalone (see test/integration), a bridge script must be loaded from the /testem.js URL, which would only exist when the HTML is served by Testem. Do you tend to ignore this 404, or is this handled by ember-cli?