Match the test to the failure
Use focused tests for deterministic rules such as rounding, status transitions, or required fields. Use integration tests when correctness depends on the database, transactions, or permissions. Reserve browser journeys for behavior that depends on the complete interface and server interaction.
Keep important boundaries real
Suppose an invoice must never receive two numbers. A test that mocks away the transaction cannot demonstrate that property. Exercise the database behavior with isolated records and verify both the result and the persisted state. Conversely, calling a live email provider in every calculation test adds unrelated failure points.
Make test data independent
Create identifiable temporary records and remove only those records afterwards. Avoid assumptions about execution order or a developer’s existing account. Prefer waiting for a visible state or response over fixed delays that fail on slower machines.
Treat intermittent failures as information
Capture the failed request, relevant state, and browser trace. A retry may help diagnose timing, but it should not replace investigation. Decide whether the defect is in the product, the environment, or the test’s assumptions.
Try this: For each critical workflow, identify one fast rule test, one persistence or authorization check, and one short end-to-end journey. Remove duplicate tests that add no distinct evidence.