discourse-writing-js-tests

Import setupRenderingTest from discourse/tests/helpers/component-test, not directly from ember-qunit, and use a .gjs file with an inline template to render the real component. Assert on the output with assert.dom from qunit-dom.

Use the acceptance() helper from discourse/tests/helpers/qunit-helpers, which wires up setupApplicationTest, the default pretender, and cleanup. Configure the scenario with needs.user(), needs.settings(), needs.site(), and needs.pretender() before calling visit().

Discourse ships a default Pretender server that answers common endpoints. Add or override routes with needs.pretender() in acceptance tests, using helper.response(body) or helper.response(statusCode, body) to shape responses.

Module titles are pipe-separated hierarchies where the last segment is the subject. Components use PascalCase like Integration | Component | PollInfo, while libs, utilities, services, and models stay kebab-case matching their filenames.

Run bin/qunit with the file or directory path, or use --filter with a case-insensitive substring or slash-wrapped regex to match module and test names. A running Rails server is required unless you pass --standalone.

Flakiness usually comes from forgetting to await async interactions like render, click, fillIn, and visit, or from leaking state between tests. Always await test-helper calls and rely on testCleanup to reset global state.