Starting Tests from Zero

BEER

Often developers and businesses can’t see the value that testing gives. Devs see it as a “tax”, an extra thing that slows them down from doing their “real job”. Businesses go into magical thinking mode, that Devs are always creating flawless features that deliver whatever the Business thinks it does and fits into the system.

Tests don’t slow down development, then pull the development forward. Writing “happy path” Unit Tests shows Devs what to work on next. Investing in high level End to End tests gives the Business confidence the system is working reliably and new changes aren’t dangerous.

Here’s how to get started with tests if you have non.

• Write one or more end-to-end tests (E2E). This gives confidence that the entire app is solid, at the cost of being slow and not very detailed. The main benefit is for the Business: they can see and understand the results.

Back in the day, for a shopping site, our E2E test was “create user, add item to cart, checkout, validate there’s a total cost” kind of thing. It was slow but had really obvious business value. Nowadays you’d do something like Playwright for this.

• Write lots of “happy path” unit tests, generally one per non-obvious function. These are fast and give a lot of info, but for a tiny scope: one function. Generally any time I have to think, I write a test.

Also write a unit test per bug, even if it’s just “this doesn’t work” or “expect some sort of Exception to happen here”. Tests can be vague if that gives you actionable feedback as a developer.

• publish Test Coverage! This is great as you and your team — and more importantly the Business — can see this number and how it changes over time. New code makes number go down? Write tests for the new code (or old code, if that makes sense for your team). Bug happens? Write test — number goes up — then fix the bug.

The overall goal is getting into a Value Feedback Cycle. For the Business audience, they want confidence the app is functioning as expected, that a new deploy won’t bring down the site. For the Dev audience, they want fast actionable feedback for them to complete the features. The two types of tests: End to End and Unit Tests, give this feedback to the two audiences.

Advanced: unit tests don’t cover much code. Consider adding API-level tests like with Postman. These are cheaper in that a single test checks more code, even though at a less detailed level. They’re also fun for the Business and Devs to see because a single API test makes the Test Coverage go up more than from a single Unit Test.