I followed your link... and read this:
I wrote the new Test::Harness that ships with Perl's core. I've written Test::Most and Test::Aggregate. I maintain or have co-maintainership on a number of modules in the Test:: namespace. I was invited to Google’s first Automated Testing Conference in London and gave a lightning talk (my talk on TAP is about 42 minutes into that). I was also at last year's Perl-QA Hackathon in Oslo, Norway, and I'll be at this year's Perl-QA Hackathon in Birmingham, UK. I was also the one of the reviewers on Perl Testing: A Developer's Notebook.
In short, I'm steeped in software testing. I've been doing this for years. When I interview for a job, I always ask them how they test their software and I've turned down one job, in part, because they didn't.
This is an excellent and well-balanced post (written all of two days ago...), and you should all go right now and read it. (Yes, before you watch any more episodes of “The Prisoner.” You'll understand my reference when you've read it.)
Uhh... and go ahead and finish re-reading the book, Code Complete, while you're at it.
It makes a difference ... a big difference.
And as soon as you follow all of the threads that are (already) attached to this one, you'll see what I mean... and you'll get a sense of proper balance.
Like all things in our profession, it is a balancing act, not a religion.
Nevertheless, it is a best practice, and it makes a very measurable difference.
| |
Yes, that's a really good Ovid article. I was about to say something similar here myself... I'm certainly sold on the value of test-driven development, but while a large body of working tests makes it much easier to make small improvements to the code, it does have the draw-back of acting as a kind of institutional weight on the design,
making big changes much harder in many cases.
| [reply] |
| [reply] |
