Explore

Return a generic, safe message to clients while logging full details server-side. Leaking stack traces, SQL, or file paths aids attackers and confuses users.

Retry idempotent operations that fail transiently (network blips, rate limits) using exponential backoff with jitter and a max attempt cap — but never retry non-idempotent or permanent failures.

Inspect the caught error, handle only the cases you understand, and rethrow the rest. A blanket catch that absorbs every error masks unrelated bugs.

Await promises inside try/catch and never leave a promise unhandled. An unhandled rejection can crash the process or silently drop a failure.

Model predictable outcomes (validation, not-found, parse failures) as typed return values; reserve throwing for truly exceptional conditions. This makes failure paths explicit and type-checked.

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

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

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

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

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

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

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

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

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

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

Enforce branch protection on main: require pull-request review and passing CI before any merge.

Keep large binary assets out of normal Git history; track them with Git LFS to avoid permanently bloating clones.

Prefer squash or rebase merges (per team policy) to keep main history linear and easy to read, bisect, and revert.

Link commits and pull requests to their tracking issue or ticket so changes stay traceable to their why.

Avoid force-pushing branches others build on; rewriting shared history destroys collaborators' work.

Keep generated output and installed dependencies out of version control by listing them in .gitignore.

Scope each pull request to one logical change so reviewers can understand it quickly and catch defects.

Keep feature branches small and short-lived, rebasing or merging from the base branch often to avoid drift and painful conflicts.

Structure commit messages as type(scope): subject so history is machine-readable and changelogs/versioning can be automated.