Testing Mindset And Test Types

Tests reduce the cost of changing software. They do not prove that an application has no defects; they provide repeatable evidence around the behaviours that matter most. The useful question is not "How many tests do we have?" but "Which failure would hurt users, and what is the cheapest reliable check for it?"

Choose The Smallest Useful Boundary

A unit test exercises a small piece of code without expensive infrastructure. An integration test checks a real boundary such as a database repository or HTTP client adapter. An HTTP test checks routing, validation, authentication, and response shape together. A browser test adds the real UI and JavaScript.

Use more integration when the risk lives at integration. A checkout flow cannot be trusted because its discount calculator has unit tests.

Build A Layered Suite

Start with many fast focused tests, add integration tests around storage and external boundaries, and reserve slower browser journeys for the workflows that must not break. Manual exploratory testing still matters for confusing interactions and release-specific risks.

For example, protect a price calculation with unit tests, a repository query with database integration tests, and checkout with HTTP tests plus a small browser journey. Each test earns its place by covering a risk at the cheapest useful boundary.

Common Mistakes

• Testing private implementation details instead of observable behaviour.
• Mocking every collaborator until the test no longer proves the integration works.
• Using browser automation for logic that a fast unit test could cover.
• Ignoring negative cases and failure paths.

What To Practise

• Choose an appropriate test boundary for a real change.
• Explain unit, integration, HTTP, browser, and exploratory testing roles.
• Write tests that remain useful during refactoring.