tpo-testing-guidelines

Require tests for the happy path, validation failures, authorization failures, important edge cases, persistence behavior, API behavior, and UI states where applicable. The guidelines specify these as mandatory before accepting any new feature implementation.

A bug fix requires a regression test that fails before the fix and passes after it, plus confirmation that related behavior still works. This prevents the same defect from reappearing in future changes.

Use unit tests for isolated business logic like validators and calculations, and reserve end-to-end tests for critical user journeys such as signup, checkout, or document upload. Overusing e2e tests is discouraged because they are slower and more fragile.

Treat a flaky test as a quality issue: identify the source of nondeterminism such as time, randomness, network, or shared state, then fix the test or underlying code. Ignoring it or rerunning until green is explicitly not acceptable.

No. Coverage alone does not prove quality; the guidelines require checking whether critical paths, edge cases, failure modes, and authorization rules are covered, and whether tests would actually fail if the feature broke.