|
Re: Non-obvious Code Should Obviously Be Killed
|
Posted: Jan 19, 2004 12:10 PM
|
|
> > Yes that's often said, in shorter form, as "everyone > knows > > that testing can't prove that a program works". Which > is > > true, but misses the point. What's the alternative? Not > > testing? > > The alternative is not to claim that the bug in question > should have been caught by regression tests (or, unit > tests). Sure, every bug should be caught by > testing, but that's not realistic, by far. > > Other alternatives include other quality assurance > methods, such as code reviews (of which the original entry > was an example of sorts), formal methods and other testing > methods. Reviews in general have proven to be rather > efficient in finding flaws in programs or designs.
That's exactly the point I was trying to make. Every time somebody mentions something like 'hey, I found this oddity' or 'look, a bug', the XPZ's always seem to jump out of the woodwork saying
"Precious should have run complete unit tests. Stupid nasty hackerses didn't pair program."
as if to say that any bug found HAD to be a result of some boob using some methodology other than one that seems to promote no planning or forethought, delight at ignoring efficiency whenever possible and disregarding years of hard won experience in favor of 'just solving the problem right in front of you right now'. I still don't understand how it has become generally regarded as bad practice to take care of something that you KNOW will be a problem in the future.
At least, this is what the popular notion of XP seems to entail, which is funny because if one actually reads the agile manifesto and related documents, this isn't really the case. At least, that's not what I've taken from it. However, to really adhere to the manifesto on anything large, you would need an awful lot of talented people working on the project. Really doing XP takes a level of commitment, talent, discipline and personality characteristics that just don't seem to be contained in most people I've ever met. Most of the people I know that have the talent and discipline would rather work alone, or perhaps even lose a limb, than pair program on a consistent basis. Most of the people I know that really dig pair programming as a 24-7 thing belong in marketing, not at a terminal slinging code.
On the flip side I would bet that you can take any large non-trivial project that passes all of the unit tests and has been running just fine for years and if you were to actually do something completely nuts like sit down and read the code, you would be able to find bugs just waiting to rear their ugly little heads. Check out http://www.reasoning.com/pdf/Open_Source_White_Paper_v1.1.pdf (requires registration) for one opinion on the value of code inspection in combination with testing.
To me, "... while comprehensive software testing is a vital part of any quality assurance program, it is not a panacea. Software testing, although extremely valuable, is inadequate in light of the increasing need for high reliability in very large code bases. Testing alone cannot guarantee defect-free code, nor can it ensure a sufficiently high level of software quality." jives really well with my experience. According to the XP way of thinking, you may as well not bother fixing a problem until it comes out in a test and that, to me, seems short sighted and perhaps even a bit arrogant.
|
|