Benjamin Cane

#Bengineering 🧐

Short-form distributed-systems tradeoffs, reliability patterns, lessons learned, and leadership notes — shared weekly.

29 posts August 8, 2025 → February 26, 2026
Portrait of Benjamin Cane

Subscribe to:

#Bengineering 🧐

Prefer your posts in a reader? Subscribe to the RSS feed or catch me on LinkedIn.

RSS Feed LinkedIn

Latest Drop

Portrait of Benjamin Cane
Benjamin Cane
February 26, 2026

You can have 100% Code Coverage and still have ticking time bombs in your code. 💣

I was listening to a team recently, and an engineer was discussing how a coding agent added additional tests to a project that already had 100% code coverage.

The conversation reminded me that coverage is directional and often mistaken for quality. Just because your coverage shows 100% doesn’t mean your software is fully tested.

👨‍🏫 Understanding How Coverage Is Measured

Code Coverage measures the percentage of executable lines that run during code tests. Executed doesn’t mean well-tested.

Just because every function runs doesn’t mean it’s free of logic errors or safe.

😃 Happy Path Testing

A common challenge teams face with testing is focusing too much on the happy path.

Suppose you have a function that accepts an array. In your tests, you always pass 5 elements — because that’s the expected usage. Coverage shows all branches executed. You’re good, right?

What happens if you pass 4 elements? Or 0?

If you never test fewer than 5, how do you know? You may say: “But wait, it’s only ever called with 5 elements.” That may be true, for now.

⚠️ Protecting Against Your Future Self

Code is rarely static; someone will come along and change things. That might be you, it might be someone else.

Eventually someone changes that function. Will they add tests for new edge cases? Maybe. Assume they won’t.

When you write tests, don’t just focus on how you know a function is going to be used; also include tests that misuse the function.

Rather than sending an array with 5 elements, send one with 4, 0, and send a nil value.

Rather than sending strings that match an expected pattern, send junk that doesn’t.

Does the function still behave correctly? Should it?

The more you test outside the happy path, the more resilient your code becomes — and the less likely it is to break later.

🧠 Final Thoughts

Code coverage is a guide, don’t let it give you false confidence. Test the happy path, and the unexpected ones. Validate function outputs against the input you provide.

100% Coverage is easy. Writing reliable code is not.

Previous Posts

  • February 19, 2026 Getting More Out of Agentic Coding Tools
  • February 12, 2026 Why is Infrastructure-as-Code so important? Hint: It's correctness
  • February 5, 2026 Optimizing the team’s workflow can be more impactful than building business features

Archive

  • February 26, 2026
  • February 19, 2026
  • February 12, 2026
  • February 5, 2026
  • January 29, 2026
  • January 22, 2026
  • January 15, 2026
  • January 8, 2026
  • January 1, 2026
  • December 26, 2025
  • December 19, 2025
  • December 12, 2025
  • December 5, 2025
  • November 28, 2025
  • November 21, 2025
  • November 14, 2025
  • November 7, 2025
  • October 31, 2025
  • October 27, 2025
  • October 24, 2025
  • October 10, 2025
  • October 3, 2025
  • September 26, 2025
  • September 19, 2025
  • September 12, 2025
  • September 5, 2025
  • August 22, 2025
  • August 15, 2025
  • August 8, 2025

Made with Eleventy and a dash of #Bengineering energy.