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).
Test observable behaviour with paired enabled/disabled assertions, not CSS properties
Assert real outcomes (element visible in viewport after scroll) instead of CSS like position:sticky, and pair enabled/disabled cases to guard against false positives.
Bad example
| 1 | test('header is sticky', async () => { |
| 2 | const header = page.getByTestId('header'); |
| 3 | // Asserting the CSS implementation detail |
| 4 | await expect.element(header).toHaveStyle({ position: 'sticky' }); |
| 5 | }); |
| 6 | // No test for the disabled case, and it never proves the header |
| 7 | // actually stays visible when the user scrolls |
Explanation (EN)
The test inspects the CSS `position: sticky` rather than the behaviour it is supposed to produce. It passes even if stickiness is broken by an overflow/parent issue, and there is no disabled-case test, so a regression that always renders the header would still go green.
Objašnjenje (HR)
Test provjerava CSS `position: sticky` umjesto ponasanja koje bi trebao proizvesti. Prolazi cak i ako je ljepljivost pokvarena problemom s overflowom/roditeljem, a nema testa za iskljuceno stanje, pa bi regresija koja uvijek prikazuje zaglavlje i dalje bila zelena.
Good example
| 1 | test('sticky header: visible after scroll when enabled', async () => { |
| 2 | render(<Component stickyHeader />); |
| 3 | await page.scrollTo(0, 1000); |
| 4 | await expect.element(page.getByTestId('header')).toBeInViewport(); |
| 5 | }); |
| 6 |
|
| 7 | test('sticky header: scrolls away when disabled', async () => { |
| 8 | render(<Component stickyHeader={false} />); |
| 9 | await page.scrollTo(0, 1000); |
| 10 | await expect.element(page.getByTestId('header')).not.toBeInViewport(); |
| 11 | }); |
Explanation (EN)
The tests scroll and assert what the user actually experiences (header in/out of viewport), and pair the enabled case with the disabled one. The disabled test fails if the feature is wired up wrong, protecting against a false positive where the assertion would pass regardless.
Objašnjenje (HR)
Testovi skrolaju i provjeravaju ono sto korisnik stvarno dozivljava (zaglavlje u/izvan viewporta) te uparuju ukljuceno stanje s iskljucenim. Test za iskljuceno stanje pada ako je znacajka krivo spojena, sto stiti od laznog pozitiva gdje bi tvrdnja prosla bez obzira na sve.
Notes (EN)
The enabled/disabled pairing principle generalizes to any toggleable feature, not just sticky positioning.
Bilješke (HR)
Nacelo uparivanja ukljuceno/iskljuceno generalizira se na bilo koju znacajku koja se moze ukljucivati, ne samo na ljepljivo pozicioniranje.
Exceptions / Tradeoffs (EN)
Asserting CSS directly is acceptable for pure unit tests of a style helper where no real layout/viewport is available to observe behaviour.
Iznimke / Tradeoffi (HR)
Izravno provjeravanje CSS-a prihvatljivo je za ciste jedinicne testove pomocne funkcije za stilove gdje nema stvarnog layouta/viewporta za promatranje ponasanja.