Rules Hub
Code Ruleset
Rule priority, scope & exceptions
Use this to align rules with the senior-level structure (P0/P1/P2, scope, exceptions/tradeoffs).
Add a custom failure message to non-obvious or computational test assertions
For an assertion whose intent isn't obvious from the raw comparison (e.g. comparing computed bounding-box coordinates), add a custom failure message describing what's actually being checked — it lets a failure be understood immediately from the test output alone, without re-deriving the test's intent from surrounding code.
Bad example
| 1 | expect(dropdownRect.top).toBeGreaterThanOrEqual(triggerRect.bottom - 1); |
Explanation (EN)
Raw numeric differences alone do not explain which UI behavior failed.
Objašnjenje (HR)
Sama brojčana razlika ne objašnjava koje ponašanje UI-ja nije ispravno.
Good example
| 1 | expect(dropdownRect.top, 'Expected dropdown to be below its trigger').toBeGreaterThanOrEqual(triggerRect.bottom - 1); |
Explanation (EN)
The failure message states the intent directly, so a broken test is immediately understandable from its output.
Objašnjenje (HR)
Poruka o padu testa izravno navodi namjeru, pa je pokvareni test odmah razumljiv iz njegovog izlaza.
Notes (EN)
For computed or geometrical assertions, make the failing test state the intended invariant and relevant measured values.
Exceptions / Tradeoffs (EN)
Do not duplicate self-explanatory matcher output. Use the custom-message mechanism actually supported by the test runner.