When I discuss testing, I prefer to frame it not as a burden, but as a reason to smile. Testing well—unit, integration, and end-to-end—means fewer late-night emergencies, fewer trips back to the drawing board, and more confidence that what we deliver actually works. That’s worth smiling about.
Which Tests to Write?
One of the first questions teams often ask is: Which tests should we write? Should they be for the backend, the frontend, or both? And how much of each? The truth is, a healthy mix matters.
I usually describe it in terms of the testing pyramid:
- Unit tests form the foundation. They’re small, fast, and easy to write. In one project, nearly 87% of our ~3,000 tests were unit tests.
- Integration tests make sure the pieces work together. They’re slower, but necessary; if the parts don’t play nicely together, the system doesn’t work.
- End-to-end tests validate complete workflows, the way a user experiences them. Even if everything else works, if the workflow fails, the business fails. We keep these focused, covering critical paths rather than every edge case.
That distribution—lots of unit tests, some integration tests, and a handful of end-to-end tests—keeps things balanced.
Since running those analyses a few years ago, I’ve changed, so the focus is no longer on unit vs. integration tests. I’ll write about that in another post.
Why We Smile
We smile because testing done well changes the way we work:
- Fewer surprises: We rarely need to throw away weeks of work because stakeholders say, “That’s not what we wanted.” Our conversations, scenarios, and tests keep us aligned.
- Shared understanding: By writing tests in a Given-When-Then style, non-technical folks can help us validate that we’re building the right thing.
- Confidence to change: Clean, well-structured tests give us the safety net to refactor and improve our code without fear of breaking things.
On one team, we grew our test suite by more than 50% over three months, and yet the distribution across unit, integration, and end-to-end remained consistent. That told me we weren’t just adding tests for the sake of coverage; we were building them into the process naturally.
What About Code Coverage?
People often ask, ‘What about code coverage?‘ My answer: It’s not the point. Code coverage numbers can be gamed; tests without assertions still “increase coverage.” What matters is feature coverage: every user story has automated tests to verify it. That’s the measure that makes business sense. And as it turns out, this shift in perspective still guarantees we have high code coverage.
The Process Matters
The real magic comes from how testing is woven into the process:
- Backlog refinement brings clarity of purpose (“In order to… As a… I want to…”).
- Sprint planning expands those stories with scenarios and Given-When-Then examples.
- Tasks always include tests: front end, back end, integration, and end-to-end.
- Design sessions define the contracts so frontend and backend can work in parallel.
- End-to-end tests validate the actual workflows after features are demoed and approved.
This process means testing isn’t an afterthought. It’s part of how we build from the very beginning.
Wrapping Up
Testing isn’t just about preventing bugs. It’s about creating confidence, clarity, and collaboration. It’s about freeing teams to focus on solving the right problems instead of firefighting the wrong ones. And when you see your system working smoothly, your users happy, and your stakeholders nodding in approval, you can’t help but smile.
We test, therefore we smile.
Here’s a complete recording of a presentation I gave on this topic:
Leave a Reply