Once upon a time someone told me that programmers can’t test their own code. I can’t remember who told me this, but I’ve been repeating it ever since.
Most of the work I do is as a solitary programmer. This is true for my personal projects as well as work I get as a freelancer and almost everything I’ve done as part of a bigger team. In some cases I’ll have people who test for me, in others I have to organise testing myself.
This is the bit where I boldly state, “a programmer can’t test their own code,” and pass it on to someone else.
Now, you can write unit tests for some things, but when you’re dealing with a project which is mostly based on user interaction, you don’t get very far with that, and when you’re as heavily reliant on asynchronous HTTP calls as most javascript heavy web sites and server-communicating mobile apps are, then it becomes much more difficult to write automatic tests that capture the sorts of problems that real users will encounter.
So, we need a human tester.
Then I thought about it, why can’t I test my own code? The theory I had been working to was that I knew my way around the software, I would subconsciously avoid sections of the site or app or whatever that I wasn’t confident about.
Of course, this is the bit where the people who call themselves software engineers (or testers, but then that’s kind of the point of this post) rather than programmers will start screaming about test plans.
And they’re right, but if you can find me 1 solo programmer who has a comprehensive test plan for the project they’re working on, then I’ve already tripped over a hundred or so that don’t, yeah, this includes me.
Of course, everyone already knows this, I’m not writing anything new here, except of course that old refrain that I’d been hanging on to (and to which, I’m sure, cling many other programmers) needs to be changed, it’s really:
Programmers don’t want to test their own code.
Which has the sad implication for me that I CAN test my own code, I just have to put in the extra effort to do so.