3 min read
So guys, why do we test?
On a dog walk I hit tip 66 of "The Pragmatic Programmer" again "Testing Is Not About Finding Bugs" and it kicked off an argument between the tester in me and the developer in me. Here's how I'm trying to let the tester win.
I was walking my dog the other day, and usually when I do that I listen to an audiobook, the one I'm listening to right now is the latest edition of the classic, "The Pragmatic Programmer", I like to go back to some influencing books for me once in a while, especially when I have to distract myself while my dog sniffs stuff in our way.
And of course on our latest walk I got tip 66 of the book again "Testing Is Not About Finding Bugs", and that tip triggered an internal dialog in me, the inner tester in me always finds it captivating and the developer in me finds it confusing.
It's not like I have different personalities, but I switch between roles often, and when I write tests as a developer I usually think about, "oh I want to check this doesn't break, and I want to make it easier for myself to reproduce issues" but when I test as a tester or look at tests during reviews of other people's code, I want to learn, I want to discover, I want to experiment and try ideas.
So what is tip 66 really saying? Not that bugs don't matter, but that catching them is a side effect, not the end game. The point of a test is the thinking it forces out of you, because a test is the first user of your code, and writing it makes you ask how the thing should behave before you trust that it does. The bug you catch is a bonus you find along the way, and the thinking is what the tester in me already does.
So maybe that is exactly what tip 66 is for, to let the tester teach the developer. The next test I write, I don't want it to only ask "does this break?", I want it to ask "what can I learn here?", so the developer in me evolves and takes some extra steps, instead of just being happy the test suite is green.
So these are the things I will try, and maybe you can try too if you have multiple roles fighting inside you:
- Before writing a test, I will write down the question I want answered, not just the case I want to pass
- Add one test with no obvious expected result, just to see what the code really does
- After a test goes green, note one thing I learned, and if it's nothing, it was just a checkbox (also, this is a reminder to buy a notebook)
- Test the edges I'm curious about, I'm curious as a tester, I should be more curious as a developer
- For every "does this break?" test, I'm gonna try to write one "what happens when…?" test next to it
Well, I hope you enjoyed the post, and remember, if you find yourself at a cafe with your inner tester and developer discussing, don't do it out loud if you don't want people to look at you weirdly.
References
- David Thomas & Andrew Hunt, The Pragmatic Programmer, 20th Anniversary Edition — Tip 66, "Testing Is Not About Finding Bugs": https://pragprog.com/titles/tpp20/the-pragmatic-programmer-20th-anniversary-edition
- James Bach & Michael Bolton, Rapid Software Testing — testing as discovery, learning and investigation: https://rapid-software-testing.com
- Michael Bolton, Testing vs. Checking — exploring to learn vs. confirming a known answer: https://www.developsense.com/blog/2009/08/testing-vs-checking/