discourse-writing-rspec-tests

Structure tests by public entry point using describe blocks like ".call" or "#execute", use fab! for shared records, and assert on observable outcomes like persisted state or response bodies. Follow the same conventions as Discourse core specs.

Place specs in spec/requests/ named after the controller, group by action with describe "#action_name", sign in users inside the action block, and assert on response status, parsed_body, and persisted state rather than internal method calls.

fab! uses TestProf let_it_be for records shared across examples and cannot depend on per-example let values. Use let for lazy per-example values, let! when a record must exist before the action, and inline Fabricate for single-example records.

Place system tests in the theme's spec/system directory, use upload_theme or upload_theme_component helpers, and run them from the Discourse root with bin/rspec tmp/themes/my-theme/spec/system after cloning into tmp/themes.

Flakiness usually comes from racing transient UI states or asserting on stale element references. Use Capybara matchers like has_css? that re-query the DOM, hold transient states with with_pending_requests, and never negate has_css? with a boolean.

Wrap the operation in DiscourseEvent.track_events or MessageBus.track_publish block helpers, which capture triggered events or published messages and return them for assertion, avoiding mocks of internal trigger or publish calls.