Re: Testing methodology, best practices and a pig in a hut.

That paper was interesting, worth signing up to read.

I thought I was going to disagree, because it started with some bold words, but ended up at a fairly mild conclusion: That practices should be evaluated in the context of the business requirements of the project. I.e. look at the real cost of failures and balance that with the cost of practices designed to minimize failure.

Obviously, I can't speak for everybody here, but are there people that think otherwise? Preventing 90% of issues is fairly easy. Preventing 99% is hard. 99.9% is incredibly hard, and so on and so on. Obviously, you have to stop somewhere. And to decide where exactly to stop, you have to sit and think what the real cost of failure is. Will a small fraction of customers be driven away by the bug? Will embedded systems need to be recalled? I think that everybody goes through this "How good does it have to be, how much effort will it take to get there" evaluation when thinking about a project.

Talking specifically about the Test::* suite, I haven't seen zealotry here. I see comments like "Use of Test::Whatever is very beneficial when I use it." I've been taking that to mean "I use it where it makes sense, but not where it isn't an economic use of my time." I may be way off, but I don't think people are advocating cargo-culting use of Test::* modules into all projects.

Comment on Re: Testing methodology, best practices and a pig in a hut.

Replies are listed 'Best First'.
Re^2: Testing methodology, best practices and a pig in a hut. by Anonymous Monk on Feb 27, 2008 at 14:27 UTC
It's not about "a better way" or "the best way." It's about putting thought into the needs of a project and deciding what the best plan of attack is, not blindly doing either what you've done before or what everybody else is doing. If you say "We've always got to have extensive Test::* driven automated testing," you are burning a pig in a hut.	[reply]
Re^3: Testing methodology, best practices and a pig in a hut. by kyle (Abbot) on Feb 27, 2008 at 16:15 UTC
You can lead a monk to knowledge, but you can't make one think. Some will think. Some will not. I personally think that a discussion of best practices/principles for testing or anything else should begin with encouragement to think. For those who have not the inclination to think, the capacity to think, or the experience to think clearly, a list of rules is better than no rules at all.	[reply]


go ahead... be a heretic
	PerlMonks