Testing Rules | BeforeMerge

Pricing Blog Contributors Install Guide

Explore
Testing

Testing

v1.0.0

Reviews test quality across unit, integration, and E2E layers — test isolation, assertion clarity, factory patterns, and coverage gaps. Tests that pass but do not actually verify behavior create false confidence that leads to production incidents.

13 rules

1 categories

Quality(13)

Make tests deterministic — no real clock, network, or randomness

Inject or mock time, network, and random sources so tests produce the same result every run.

Maintain Test Isolation

Every test must be independent — no shared mutable state, no execution order dependencies. When tests share state, they pass in isolation but fail together (or worse, fail randomly), creating flaky CI that wastes hours of debugging time.

Automate Testing checks on every PR

BeforeMerge scans your pull requests against all 13 Testing rules automatically. Get actionable feedback before code ships.

Join Waitlist Browse All Rules

AI-native code review knowledge base. Structured rules that catch what linters miss.

Product

Features
Explore
Pricing
Docs
GitHub

Company

About
Blog
Contributors
Contributing

Legal

Privacy Policy
Terms of Service
MIT License

© 2026 BeforeMerge. Built by

Test Isolation

HIGH

Clean up shared state between tests

Reset databases, mocks, globals, and temp files in teardown so each test starts fresh.

Test Behavior, Not Implementation

Test what the code does (outputs, side effects), not how it does it (internal method calls, private state). Implementation-coupled tests break every time you refactor, even when behavior is unchanged — making tests a liability instead of a safety net.

TestingqualityUnit Testing

Mock at boundaries, not internal collaborators

Stub external systems (network, DB, filesystem) but let internal objects run for real.

Test edge cases and error paths, not just the happy path

Cover empty inputs, boundaries, and failure modes where most real defects live.

Follow the test pyramid — many unit, fewer integration, fewest E2E

Favor fast isolated unit tests; reserve slow integration and E2E tests for critical flows.

Name tests by the behavior they verify

Use descriptive names stating condition and expected outcome so failures read like a spec.

Avoid conditionals and loops in test logic

Keep tests straight-line; branching or computed expectations can hide bugs in the test itself.

Treat coverage as a signal, not a target

Use coverage to find untested risk, not as a quota that rewards assertion-free tests.

Use Factories Over Fixtures

Use factory functions (e.g., `createUser({role: 'admin'})`) instead of static JSON fixtures. Factories let you create exactly the data each test needs with sensible defaults, while fixtures force you to maintain large JSON files where a change to one test's data breaks another test.

TestingqualityFactories

Structure tests with Arrange-Act-Assert

Separate setup, the single action under test, and assertions into clear phases for readable tests.

Assert one logical concept per test

Each test should verify a single behavior so a failure points to exactly one cause.

Features Explore

Rules Skills Knowledge Prompts

Pricing Blog Contributors Install Guide

Testing Review

A review skill for test code quality, structure, and coverage strategy.

What it covers

Test isolation — no shared mutable state between tests, proper setup/teardown, deterministic ordering
Assertion quality — specific assertions over toBeTruthy, testing behavior not implementation, snapshot discipline
Test structure — arrange/act/assert pattern, descriptive test names, avoiding logic in tests
Factory patterns — test data builders, avoiding hardcoded fixtures, minimal data for each test case
Coverage strategy — critical path coverage, edge cases, error paths, not chasing percentage metrics
E2E discipline — page object patterns, stable selectors, retry-aware assertions

When to use

Run this on any PR that adds or modifies tests. Especially valuable during test suite refactors or when test flakiness becomes a recurring problem.