How We Approach Testing (Without Obsessing Over Coverage Numbers)

We don't chase 100% code coverage. We test the things that matter and skip the things that don't. Here's how we decide which is which.

Testing is one of those topics where the internet gives you two equally bad options: test everything obsessively, or don't test at all and "move fast." The right answer is in the middle, and it depends on what you're building.

Integration tests first

Integration tests that exercise your real endpoints, database, and business logic catch the bugs that actually matter. A test that says "when a user submits an order, the order appears in the database and an email is sent" tells you the system works. A unit test that says "this function adds two numbers" tells you very little.

What we always test

• Authentication and authorization - who can access what
• Payment and billing flows - money cannot be wrong
• Core business logic - the thing your product actually does
• API contracts - request/response shapes that clients depend on
• Data migrations - ensure they're reversible and don't lose data

What we usually skip

• Pure UI component tests (visual regression tools are better for this)
• Getter/setter functions and trivial mappings
• Framework code - React, Express, etc. are already tested
• Tests that just assert the mock was called (you're testing your test setup)

Coverage numbers are a trap

80% coverage with the wrong 80% tested is worse than 40% coverage of the right 40%. Coverage tools don't know which code is important. You do. Focus on confidence, not percentages.

Ben Arledge

CEO & CTO, CloudOwl