What causes "Every test should have either `{prefix}.assertions( )` or `{prefix}.hasAssertions()` as its first expression." in oxc-project/oxc?

Apply the autofix or manually add expect.hasAssertions() as the first statement of the test body.

oxc-project/oxc · warning · OxcDiagnostic

Every test should have either `{prefix}.assertions(<number o

Error message

Every test should have either `{prefix}.assertions(<number of assertions>)` or `{prefix}.hasAssertions()` as its first expression.

What it means

This is oxlint's 'jest/prefer-expect-assertions' diagnostic. It reports a test body that does not begin with expect.assertions(<n>) or expect.hasAssertions() (the local expect alias is resolved via resolve_expect_local_name). Those guards make Jest verify that the expected number of assertions actually ran, catching async tests that silently skip their expects. The rule provides a fixer that inserts the missing first statement.

Source

Thrown at crates/oxc_linter/src/rules/jest/prefer_expect_assertions.rs:22

use oxc_semantic::NodeId;
use oxc_span::Span;
use oxc_syntax::scope::ScopeId;
use serde::Deserialize;
use std::borrow::Cow;

use crate::{
    context::LintContext,
    fixer::RuleFix,
    rule::{DefaultRuleConfig, Rule},
    rules::shared::prefer_expect_assertions::{
        CallbackBody, DOCUMENTATION, PreferExpectAssertionsConfig, PreferExpectAssertionsRuleImpl,
        resolve_expect_local_name, should_check,
    },
    utils::collect_possible_jest_call_node,
};

fn have_expect_assertions(span: Span, prefix: &str) -> OxcDiagnostic {
    OxcDiagnostic::warn(format!(
        "Every test should have either `{prefix}.assertions(<number of assertions>)` or `{prefix}.hasAssertions()` as its first expression.",
    ))
    .with_help(format!("Add `{prefix}.hasAssertions()` or `{prefix}.assertions(<number>)` as the first statement in the test."))
    .with_label(span)
}

#[derive(Debug, Default, Clone, Deserialize)]
pub struct PreferExpectAssertions(Box<PreferExpectAssertionsConfig>);

impl std::ops::Deref for PreferExpectAssertions {
    type Target = PreferExpectAssertionsConfig;

    fn deref(&self) -> &Self::Target {
        &self.0
    }
}

declare_oxc_lint!(

View on GitHub (pinned to e1e7af627c)

Solutions

Apply the autofix or manually add expect.hasAssertions() as the first statement of the test body.
If you know the count, use expect.assertions(2) so Jest enforces exactly two assertions.
If the rule is too noisy for your style, disable it in .oxlintrc.json ("jest/prefer-expect-assertions": "off").
Inline-suppress individual tests where the count is unknown with // oxlint-disable-next-line jest/prefer-expect-assertions.

Example fix

// before
it('maps values', () => {
  expect(map('a')).toBe(1);
});

// after
it('maps values', () => {
  expect.hasAssertions();
  expect(map('a')).toBe(1);
});

Defensive patterns

Strategy: validation

Prevention

Start async/callback test bodies with expect.hasAssertions() (or expect.assertions(n)).
Decide team-wide whether the rule is on; if on, add the guard when writing the test, not later.
Use the rule's autofix during migration batches instead of hand-editing every test.

When it happens

Trigger: Enable the rule (shared implementation with rules/shared/prefer_expect_assertions, honoring should_check and the CallbackBody config) and lint it('x', () => { expect(a).toBe(b); }) — a test whose first body statement is not a call to <expect-local>.assertions or <expect-local>.hasAssertions. The message interpolates the resolved expect prefix.

Common situations: Enabling strict Jest presets across an existing suite flags nearly every test at once. Callback/Promise tests written before expect.assertions existed are the historical reason the API exists; teams adopting it hit the rule during config migration or when copying old tests into a stricter project.

Related errors

AI-assisted analysis of oxc-project/oxc@e1e7af627c (2026-08-20). Data as JSON: /api/errors/0480c65e868e0452. Report an issue: GitHub.