Presentation: Testing is Overrated
In this talk from RubyFringe, Luke Francl wonders if Testing is overrated.
The question is certainly provocative nowadays, with TDD and other practices becoming ever more popular. However, Luke shows how testing can't catch all problems and how energy spent on achieving 100% test coverage would be better spent on other activities such as Code Reviews.
Watch Luke Francl's "Testing is Overrated".
Re: Missed the point
Franz Allan See
When you write a code with test, other developers can go in and change it and see if they broke anything functionality that you did.
And if during the course of usage, a bug arises, you can debug your code easier if you have tests all around. Because those states who are not tested are most likely be the suspect (thereby decreasing the states that you have to go through).
Having unit tests will not guarantee a bug-free system. But it should speed things up in fixing them.
testing is just a substitute
Exposure to the real world is actually better, since it better (very effective, actually) to find errors in the specifications. However, making errors in the real world, when you are developing money-moving software with more than 10 digits for the amount, is not so practical.
Value of testing
With that said, code testing does improve quality of implemented code and features (in my own experience), it provides a firm base to validate the aging code (as during refactoring) and new features against and, not lastly, provides a form of code documentation (most importantly the intention behind the code -- not just mere comments in code -- which will be valuable years later, as some code runs and it is maintained by many people for long periods of time.) I would not discard here the sense of confidence good tests passed inspire in developers, especially important during difficult project periods. I would also think that scripting/dynamic languages need more testing because of the absent/reduced compiler-supported validation. The problem with insufficient negative case testing -- testing for what could go wrong -- comes from the fact that, in reality, too little attention is given to that -- starting with requirements, use cases, etc -- at a project/product technical and management level, and that is something we can do something about.
I have not seen code reviews ensure quality of code in a sustainable manner, either as a code reviewer or reviewee -- unless if that is part of pair-programming -- but that could be subjective.
To conclude, I believe we should be doing (more) testing but understand and act upon its limitations and benefits vs. costs for each particular situation.