Rules Hub
Coding Rules Library
Rule priority, scope & exceptions
Use this to align rules with the senior-level structure (P0/P1/P2, scope, exceptions/tradeoffs).
Inline single-use test mocks instead of an extra variable
Define a one-off mock inline in the return value rather than declaring a redundant intermediate variable.
Bad example
| 1 | describe('Widget', () => { |
| 2 | const push = vi.fn(); |
| 3 |
|
| 4 | beforeEach(() => { |
| 5 | vi.clearAllMocks(); |
| 6 | mockedUseRouter.mockReturnValue({ push }); |
| 7 | }); |
| 8 | }); |
Explanation (EN)
Hoisting a one-off mock into its own variable adds an extra line and an indirection the reader has to track, without giving the test anything reusable.
Objašnjenje (HR)
Izdvajanje jednokratnog mocka u zasebnu varijablu dodaje suvišnu liniju i indirekciju koju čitatelj mora pratiti, a testu ne daje ništa što se ponovno koristi.
Good example
| 1 | describe('Widget', () => { |
| 2 | beforeEach(() => { |
| 3 | vi.clearAllMocks(); |
| 4 | mockedUseRouter.mockReturnValue({ push: vi.fn() }); |
| 5 | }); |
| 6 | }); |
Explanation (EN)
Defining the mock inline keeps the setup compact and self-contained when the value is not referenced again elsewhere.
Objašnjenje (HR)
Definiranje mocka inline drži setup kompaktnim i samodostatnim kad se vrijednost nigdje drugdje ponovno ne koristi.
Notes (EN)
Keep a named variable only when you assert against the mock later (e.g. expect(push).toHaveBeenCalled()). If you need the reference, inlining is wrong.
Bilješke (HR)
Imenovanu varijablu zadrži samo kad kasnije radiš asertaciju nad mockom (npr. expect(push).toHaveBeenCalled()). Ako ti treba referenca, inline nije ispravan.
Exceptions / Tradeoffs (EN)
When the same mock is referenced in assertions or reused across multiple cases, a named variable is the right choice.
Iznimke / Tradeoffi (HR)
Kad se isti mock koristi u asertacijama ili dijeli između više testova, imenovana varijabla je ispravan izbor.