Clear questions and runnable code
get the best and fastest answer
Testing methodology, best practices and a pig in a hut.by BrowserUk (Pope)
|on Feb 27, 2008 at 04:31 UTC||Need Help??|
This isn't much of a meditation. More a reference to a couple of pieces of further reading on recent topics prompted by an enquiry.
Anyone who's been around here for a while (and still bothers to read my posts), will know I have a distaste for Test::* suite of modules. I'm not opposed to testing. Indeed I spent a good part of my career doing pretty much nothing else and am 100% convinced of the need for and value of testing as an integral part of the software development process.
My argument is not about whether you test. It's about what you test. When. And how.
Being a vocal member of a usually silent majority(?), speaking out against practices advocated by the more vocal advocating minority, causes consternation: Why does he think he knows better than all those others?
The answer of course is, I don't. But that doesn't mean I'm wrong either. There is no one right way to do most anything. Some ways work better than others in certain environments; for particular teams or individuals; for particular project types or goals.
Just as getting from A to B may be better accomplished using a car, minivan, pick-up truck, bus, 18-wheeler, train or bike, depending upon the requirements of the journey involved. So RAD, Agile, XP, or waterfall development models will each suite some projects/teams/environments better than others.
If you are a someone who's programming skills are evolving through doing, you start out writing small scripts and debugging by trial and error. As your skills improve and your programs get more complex, you reach a point where you look for a better way. If there are a set of tools and frequent references to those tools and the underlying methodology they implement, you will take a look and give them a go. And if those tools and methodology are an improvement over your previous (non-)practices, you are likely to adopt them and become both practitioner and advocate.
Anything is better than nothing. And if you've only tried one thing, then that thing is going to be the anything that you use. But if you have experienced more than one methodology, whilst you may have an opinion as to which you prefer, it would be a rash man who elected to ignore the alternatives for every project he becomes involved in. Rasher still to recommend it, to the exclusion of all others, for projects that he has only the barest of knowledge of.
There is an old saying:
Good judgement comes from experience, and experience comes from bad judgement.
And I know of no field where that is more applicable than software development.
I've also been known to express concerns that a certain set of "Best Practices" has had a detrimental affect upon the way the use of Perl's full syntactic power is perceived. These concerns relate not to the detailing of the best practices themselves, but to their codification as a set of rules enforceable through automation without a full understanding of their implications.
Try as I might, I can come up with no shorter explanation than the following. Drawn from a paper Why Software Quality Assurance Practices Become Evil! (pdf)
(UPDATE: The preceding link doesn't work without registration. However, going to here and clicking the link labelled "View Content Detail:" does))
that I highly commend to all those that see no merit in my apparently contrarian opinions. And those who believe that they are currently using the One True Way of software development and testing. It is only 11 pages, and just might give a few of you pause for thought.
The pig in a hut
For an explanation of that, you'll have to read the paper above :)
Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
"Science is about questioning the status quo. Questioning authority".
In the absence of evidence, opinion is indistinguishable from prejudice.