It’s about all the other things that can happen.
Why do you test?
People usually think testing is a chore and don’t do it because “it’s already working”.
Except when it isn’t, and then they rush to fix it and hope that no one will complain this time.
Sure, the happy path is working. But what if you get an error? What if you try something different?
Why testing is not about the happy path
Especially when you add ZOMBIES to the mix:
- Z – Zero
- O – One
- M – Many (or More complex)
- B – Boundary Behaviors
- I – Interface definition
- E – Exercise Exceptional behavior
- S – Simple Scenarios, Simple Solutions
Doing that forces you to add scenarios that will actually test your application in ways that the happy path never will.
And best of all? You can easily find common errors that a user, malicious or not, will find.
The costs of testing vs. not testing
Some people like to talk about the cost of “wasting time” creating tests.
Well, someone showed me the latest example of “testing in prod”: the UK air traffic control fiasco.
I’m not that familiar with what happened, but the overview is that some company inputted wrong or invalid data, and that brought down everything leaving hundreds of flights canceled and costing millions. From the overview I got, two points kilometers apart had the same identifier, and the system was designed to fail safely and stop everything when it couldn’t process data.
In any case, duplicated data is something so common that is usually one of the first things we test. Not only that, usually you add one layer in the frontend and then another on the backend, sometimes you even add constraints in your database.
I’m not saying they don’t have tests in place, I expect they do. But I also saw similar (albeit not that costly) problems surfacing because there was no testing in place.
Never trust the users… or even the developers!
I’m talking about your users, malicious agents, your colleagues, and even you! Trust no one!
No testing means you’re just blindingly trusting people to do things exactly like the you at coding time thought it should been used and you can see that the number of people in a list of “people who know” starts really small and tends to zero.
Users will try weird things… they are users after all. Not only that, but many developers don’t have a close relationship with normal users, you might think something is weird, but it’s normal for other people. (For example: it baffles me that normal people want phone apps for things that don’t really need an app. I don’t want to download a poorly written, bloated app to be able to do something in a grocery store.)
Malicious agents love that most developers don’t like testing. If you like them… ok?
Your colleagues can sometimes be worse than the users. A hypothetical example is that they know just enough to leave a backdoor of sorts open because it’s easier for them to use that way.
Finally… you! You think you know it like the back of your hand just because you wrote the bloody thing. But that was the past you, since then you’ve grown but now have to deal with the problems left to “future you” to solve.
Guardrails are important to everyone, someone will inevitably slip, and when that time comes… it will cost, be it time and/or money, and depending on where you’re working or with what, people's lives.
Top comments (2)
Running other people's tests is also blindly trusting other developers, is it not?
Yes it is.
A test that just there to improve coverage but doesnt test can do more harm than good, not only that, a badly written test might not actually test what the code needs.
To lessen that problem, code reviews are in order or, better yet, mutation tests! (mutation tests changes the code and then run the tests because theoretically, changing the code would mean tests failing)