Do not index
Do not index
In software engineering, we're often faced with a riddle:
How can a team, armed to the teeth with unit tests, still find their code hard to change and their delivery bogged down by unexpected functionality gaps?
At Hppn, we have this nightmarish image of standing in a coal mine filled with canaries, each chirping away trying to tell us something.
And here's the catch – there are so many canaries that their chorus is deafening. And taking care of them all has become a full time job. How will we know when one topples off their perch as an early sign of danger?
Lo and behold we've found ourselves in the classic ‘too much of a good thing’ trap!
The Quality Quagmire
Let's set a more realistic scene. You're leading a software team. You've got a solid set of unit tests in place. Your code coverage? Impeccable.
Yet…something’s amiss.
Bugs and feature gaps are too common. Confidence in the code has dropped so low that sprints are being permanently extended to make room for manual testing.
New features are stuck on the backlog for months.
So what’s going on?
The Unit Testing Paradox
Now this might seem controversial but maybe we've been overdoing it with unit tests. 🤔
Like an overpopulated mine of canaries, an automatic, unthinking approach to unit testing can end up just creating lots of noise and a maintenance burden, undermining the very challenge we’re trying to tackle.
What’s the alternative?
Well firstly, we’re NOT saying all unit testing is worthless. But how do you know how many canaries you need?
Behavioural Testing: A Glimpse
At Hppn we’re a big believer in behavioural testing.
This approach is focused on understanding how your software is expected to behave in the real-world…in the hands of actual users. It's not about testing every line of code but about ensuring the software does what it's supposed to do – effectively and efficiently.
Think of it as having just the right number of canaries, so that you'll actually notice when one stops singing to signal something important.
As well as this early warning system, behavioural testing comes with many side benefits that will not only improve the quality of your code, but also keep your pipeline to production flowing smoothly.
Who Should Care?
As CIOs, CTOs, and Engineering Managers wrestling with mid to large scale applications, you are already sensing the weight of the tech debt; you know that a change is needed.
Reducing unit tests might sound radical but it's a step towards a more effective testing strategy, and more confidence in your platform.
What's Next?
In the upcoming articles, we'll delve into the specifics of behavioural testing – the techniques, tools, and real-world examples and applications. We’ve listed just a few of the questions we’ll be answering below. In the meantime, perhaps ponder this:
What are your unit tests actually telling you about the functionality being delivered to the user? Are you checking for syntax? Or are you confirming it’s valuable?
Stay tuned. We’re just starting our descent into the heart of effective testing.
--
Please share your experiences and insights. Join the conversation as we strive to optimise the path from dev to production.
--
Questions we’ll be answering in upcoming articles:
- How well do your tests reflect your acceptance criteria?
- How do you address rigidity of your code base?
- Do your tests convey the system behaviour, or the implementation details?
- Would your product manager understand the intent of your tests? [Alternate title: Could you feed your tests into AI and get a description of your feature?]
- Are your tests a first class citizen in your code base?
Written by
Written by
