Why on Earth would I test software?
Let me embark you on a journey in software engineering land…
Warning: there will be irony involved. Loads of it. If you cannot stand it, please avoid over-exposure.
Testing serves no purpose at all
Rather than waste time testing, it’s much better to focus during development and not introduce bugs to begin with.
Here, even Dijkstra was against testing:
Program testing can be used to show the presence of bugs, but never to show their absence! — Dijkstra in Notes On Structured Programming
See. Testing shows the presence of bugs. And I don’t want any bug in my program. Much less show their presence. So shoo, get away from me, testing.
Dijkstra also talked a lot about proofs, but I don’t think that applies to my favorite language, only to those weird functional thingies you can’t build any real thing with. So I should be fine.
Testing makes the bosses happy
Okay, so I really hate testing, but those pains in the neck from the infrastructure department have set up some continuous whatever platform and now my bosses can see that my code has very bad coverage.
They don’t like that one bit. They want our project to have better coverage than the other projects around… I’m not sure they know how coverage is computed exactly. And they could not tell me why it should be increased, but well… Bosses call the shots.
So now I’m forced to write tests. Such a waste of time. Like all those comments I’m forced to generate everywhere to increase the “documented API” metric… God, I hate metrics. They really waste my time.
I’ll just look at the code and make sure I have a unit test going through each of the instructions. That should keep them very happy.
Testing ensures quality
Last time we shipped, there was a stupid case nobody thought to implement and it cost our company a lot of money…
It’s great that our task management system is so broken and unusable and our version control system is so misunderstood and badly configured that nobody figured out it was my mistake.
Just in case, though, next time I should test. Everything. Just to be safe. It cannot be that hard to think of every scenario, right? How hard could it be?
Or maybe I can leave that to QA experts. Q stands for Quality. I bet A stands for Annoying. They’re the guys who always come up with bugs. It’s like they’re magicians and they invoke them. I think they’re jinxing the system.
Anyway, it’s their job to make sure that the code does what it is supposed to. I am surely not going to do anyone else’s job. That would be bad. Like that time I tried to design an interface. Ugliest UI you’ve ever seen. I still shudder when I think of it.
Testing secures code against regressions
We keep losing features I’ve introduced. I’m sick and tired of re-building and re-fixing the same stuff over and over.
If only my colleagues paid more attention to my work and tested my stuff to make sure their modifications don’t break everything… But they keep saying they don’t know and they don’t have time. Jerks.
But I’ve heard of something nice they set up in another project: anti-regression tests. The idea is to write a test to check that a feature is still there or a bug is still fixed. You run those tests every time the code is modified, so when jerks break your stuff, at least they can’t pretend they did not know.
I’m told it can even be used in continuous whatever platforms to prevent jerks from breaking my stuff… So maybe I’ll write those tests… Just so that I don’t see that bug come back for the 13th time (it’s bad luck).
Testing encourages refactoring
Okay so we tried TDD for a part of the project. Just to see what all the fuss was about.
It was torture. To have to write tests without the code under test to look at… I just was not sure what to test, really. I had to think of what the input would look like and what the output would look like… and we had to mock everything instead of using real stuff. Such. A. Pain.
But now that we have a test for each feature in our program, I know I can modify anything anywhere and check if it broke anything. It’s like magic. I can actually revamp big blocks of code and I just run the tests and it tells me exactly where stuff broke. Sometimes it’s the tests that need fixing, because we’re not doing that old feature the same way anymore, often it finds regression bugs faster than you can say “I take one step forward, two steps back”.
I’m not even scared to use my IDE refactoring tools anymore. Or strange git commands. I feel so free.
Don’t get me wrong, it is still a pain to write the tests, but god is it great to have them around!
Testing is a form of specification
I heard through the grapevine about that great framework about behavior and stuff. Sounds psychological to me. Or sociological. Maybe both. Not sure.
Anyway, it’s so awesome because the tests are easier to write and to read now. Well, they are still a pain, but less of a pain than before.
And it looks a bit like plain old English. If you squint very hard.
So the error messages when a test fails are easier to read as well. And my colleagues come less often to ask me how they broke the tests thanks to that.
Maybe if they improve the framework even more, I’ll be able to show the tests to my bosses to make sure that’s really what they want me to implement and save some time refactoring stuff that they could not convey right the first time around.
Meanwhile, I can already show it to my fellow coders so they can understand how to use and/or modify my code.
It’s magic.
Conclusion
Guaranteed free of irony.
Test first. Test often.
Whether you follow the Test-Driven Development process or not does not matter: as long as you are supposed to write tests of any kind, make sure you write them first and run them often.
That is how you’ll make the most of them. As a coder.
