Tests should verify real, intended behavior and must fail when that behavior is broken. Before adding a test, confirm it actually exercises the code path and would catch a regression — a test that passes even against the old/incorrect implementation provides no value. Assert on precise, meaningful values (actual header content, response body, instance types, redirect Location) rather than weak checks like array length, truthiness, or null/not.toBeNull(), which can hide bugs.
Avoid flakiness and non-determinism: never use Math.random() or other random data for test inputs, don’t spin up real network servers/ports in tests (prefer mocks like msw to avoid port collisions), and resolve promises on the correct event (e.g. close, not open) to prevent races.
Keep the suite lean and focused: don’t duplicate coverage that already exists elsewhere (e.g. in a lower-level module’s own tests), remove tests unrelated to the feature/module under test, and don’t over-test trivial variations — one happy-path and one failure-path case is often enough. Also ensure no .only/.skip is left in committed test code, since it silently disables other tests.
Example of a weak vs. strong assertion:
// Weak: passes even if value is wrong, or structure changes
expect(cookies.length).toBe(2)
// Strong: verifies actual content
expect(cookies).toContain('foo=bar; Path=/')
expect(cookies).toContain('foo2=bar2; Path=/')