{"record":{"id":"59df188061c34357","repo":"oxc-project/oxc","slug":"suggest-using-tobecalledwith-or-tohavebeencal","errorCode":null,"errorMessage":"Suggest using `toBeCalledWith()` or `toHaveBeenCalledWith()`.","messagePattern":"Suggest using `toBeCalledWith\\(\\)` or `toHaveBeenCalledWith\\(\\)`\\.","errorType":"validation","errorClass":null,"httpStatus":null,"severity":"warning","filePath":"crates/oxc_linter/src/rules/shared/jest_vitest/prefer_called_with.rs","lineNumber":11,"sourceCode":"use oxc_ast::AstKind;\nuse oxc_diagnostics::OxcDiagnostic;\nuse oxc_span::Span;\n\nuse crate::{\n    context::LintContext,\n    utils::{PossibleJestNode, parse_expect_jest_fn_call},\n};\n\nfn use_to_be_called_with(span: Span) -> OxcDiagnostic {\n    OxcDiagnostic::warn(\"Suggest using `toBeCalledWith()` or `toHaveBeenCalledWith()`.\")\n        .with_help(\"Prefer toBeCalledWith(/* expected args */)\")\n        .with_label(span)\n}\n\nfn use_have_been_called_with(span: Span) -> OxcDiagnostic {\n    OxcDiagnostic::warn(\"Suggest using `toBeCalledWith()` or `toHaveBeenCalledWith()`.\")\n        .with_help(\"Prefer toHaveBeenCalledWith(/* expected args */)\")\n        .with_label(span)\n}\n\npub const DOCUMENTATION: &str = r\"### What it does\n\nSuggest using `toBeCalledWith()` or `toHaveBeenCalledWith()`\n\n### Why is this bad?\n\nWhen testing function calls, it's often more valuable to assert both\nthat a function was called AND what arguments it was called with.","sourceCodeStart":1,"sourceCodeEnd":29,"githubUrl":"https://github.com/oxc-project/oxc/blob/e1e7af627c8843ab64044ed466b128fcc21a035b/crates/oxc_linter/src/rules/shared/jest_vitest/prefer_called_with.rs#L1-L29","documentation":"This is the oxlint `prefer-called-with` rule (jest/vitest plugin), diagnostic for the `toBeCalled()` matcher form. Asserting only that a mock was called proves nothing about how it was used; the rule wants the argument-asserting variants `toBeCalledWith(...)` / `toHaveBeenCalledWith(...)`. This entry (the `use_to_be_called_with` constructor) fires specifically when the parsed expect matcher chain ends in `.toBeCalled()`.","triggerScenarios":"Any `expect(mockFn).toBeCalled()` expression recognized by `parse_expect_jest_fn_call` where the matcher name is exactly `toBeCalled` (also via aliases like `it` blocks, `expect.soft`, etc.).","commonSituations":"Quick smoke tests that check a spy fired; legacy codebases written before argument matchers were widely used; auto-completed matcher names where the developer accepted `toBeCalled` instead of `toBeCalledWith`.","solutions":["Replace `expect(mock).toBeCalled()` with `expect(mock).toBeCalledWith(expectedArg1, ...)` supplying the real expected arguments.","If any invocation is acceptable, use `expect(mock.mock.calls).toContainEqual([arg])` or assert on `mock.calls.length` deliberately instead of leaving a bare toBeCalled.","If the call genuinely takes no arguments, `expect(mock).toBeCalledWith()` (zero args) still satisfies the rule and pins the arity."],"exampleFix":"// before\nexpect(loggingFn).toBeCalled();\n\n// after\nexpect(loggingFn).toBeCalledWith('user-created', 42);","handlingStrategy":"validation","validationCode":"// .oxlintrc.json\n{ \"rules\": { \"jest/prefer-called-with\": \"error\" } }\n\nnpx oxlint tests/","typeGuard":null,"tryCatchPattern":null,"preventionTips":["Treat bare toBeCalled/toHaveBeenCalled as a smell: always assert the arguments too.","Use asymmetric matchers (expect.any, expect.stringContaining) when only some args matter.","Keep the rule enabled in CI to stop weak call assertions at review time."],"tags":["jest","vitest","oxlint","testing","mocks","assertions","static-analysis"],"backgroundTag":"assert-call-arguments","analyzedSha":"e1e7af627c8843ab64044ed466b128fcc21a035b","analyzedAt":"2026-08-20T07:01:07.079Z","contentChangedAt":"2026-08-20T07:01:07.079Z","schemaVersion":2},"datasetVersion":"2026-09-14T05:17:10.506Z"}