Welcome to the 6th excuse in the Testing: Why Bother? series.
I'm going to address this excuse a little bit differently than the other ones and be more personal about it.
Reading the headline of this excuse may sound dubious to some of you, but I assure you it's not something I made up. I actually heard this excuse while I was looking for a job a while back and was interviewing for a startup company.
Something I tend to do during interviews (and I think all job candidates must do as well), is to be a little bit of an interviewer myself - asking some questions about the nature of the team I'm about to join, to see if there's a good fit to what I'm looking for in a work environment.
For me, one of these questions will always be "How do you feel about unit tests?"
I often get an answer like: "we don't really write those, but we are open for change in that matter". This is actually the common answer I get and one of the answers that I live with quite happily. However, I once got a completely different answer, that inspired some of the excuses in this series, and this excuse in particular, as I did not meet any other interviewer so confident to claim such a statement.
"Our recruitment process is one of the hardest there is. It's simply impossible to get accepted if you're not a 'rockstar', and therefore we have a team of amazing developers. This way we ensure excellent code quality and zero bugs, and therefore writing tests is simply superfluous".
While I believe it's true that a challenging job candidate screening process is an excellent way to ensure better quality products in any field and any company, I found this reasoning a bit absurd, for 3 reasons:
1) Consider the opposite situation
The first odd thing about this claim, is that by this reasoning, all mediocre developers should write a lot more tests than those 'rockstars', because they NEED those tests in order to reveal all the bugs they cause.
However, you actually must be a decent developer in order to be successful in writing good tests that reveal bugs, or else, the writing tests is too hard excuse is probably justified in your case.
Also, developers who write tests are usually the ones who care enough and are passionate enough about software development in order to make that extra effort, and IMO that alone makes them better in what they do.
I mean, can you honestly tell me there's a development job you wouldn't hire names like Uncle Bob Martin and Kent Beck, etc. to do?
So, I might have not proved my interviewer's claim wrong by this explanation, but I think you'll agree that by looking at the argument from this angle you see it's quite paradoxical, as it's not likely that if the entire team were lousy developers the team's attitude towards tests would improve.
On a side note about this reason, there was a similar claim by Tomas in the comment of my previous post in the series. I think you'll find the discussion interesting.
2) Everyone has bugs!
I'm sure that was the immediate response for most of you.
You are simply misleading yourself if you think that the people you hired aren't going to have bugs.
We are all human, we all make mistakes, and heck - I'm sure even if we build a perfect robot programmer it would have some bugs in its software, as the definition of a bug might be simply a change in requirements, and not a human error of forgetting to deal with a null pointer.
It's true - better developers are often quicker on catching bugs. they tend to make less mistakes and get to working software faster (therefore - they are better developers), but sometimes the way they achieve that special ability of writing bug-less code quickly, is simply by testing it. Does this by definition make them worse developers? I think not.
3) REGRESSION!
If you are following my list of excuses, you should be familiar with this "excuse killer" by now.
It's not only about finding the bug now, it's about ensuring the programmer who comes after you is not going to encounter it again.
Sure, now your team is assembled from amazing programmers who know all about their code and never make mistakes. But what's going to happen when a new programmer enters the project? Even if she is a rockstar developer herself, she still might lack the understanding of what the original author of that piece of code had in mind, and therefore might make a mistake in interpretation = a bug.
So, I hope you take something from this post. If it's the idea of asking "how do you feel about unit tests" in your job interview (great ice breaker on the "do you have any questions for us?" phase), if it's understanding that better developer != doesn't write tests, or if it's just getting to know me better by a personal story about a job I didn't take.
Anyways, it would be awesome if you'll spread the word about my blog, subscribe to my feed and follow me on twitter :)
It might come as a surprise, but you can actually build excellent software without a single unit test. The whole Linux kernel has no unit testing what so ever.
ReplyDeleteYou could also choose to never run the static analyzer or use the Instruments tools. Because something is possible doesn't mean that it is the best choice :-) And things change. What was once written using assembler or vanilla C is now better off being written using a newer, more powerful compiler.
ReplyDeleteI think that often the failure to use new tools like OCUnit, GHUnit, or OCMock is simply the result of programmers being reluctant to take the time to learn new techniques.
I wonder if the companies that think that they are so good that they don't need unit tests would be willing to post that statement somewhere on their website?
Nice points.
DeleteLoved your iOS testing blog BTW!
Nice points.
DeleteLoved your iOS testing blog BTW!