On Thu, 06 Oct 2005 05:42:59 -0400, Tom Allison wrote: >> So make tests that just run the scripts and then examine the outputs. >> If there are unwanted side effects you can't undo from the test then >> you need to modify the script in some way. > > Is this where 'do' comes into use?
No, I'd use 'system'. Otherwise the script will be affecting the calling environment in ways I'm not supposed to have to find out about with black box testing. >> This is why writing the tests *before* writing the code makes life so >> much easier. Still, that's hindsight. > > um... I have one problem with that. > I often don't know what the script is supposed to actually do until I'm > already writing it. Most of these are variations on a theme of log > analysis or data mining. At least one well known person has said the same thing... but he appears to be in a minority. Personally, unless you're doing the programming equivalent of doodling, I can't see how you can write something before knowing what it does. Even if you only formulate the idea a moment before writing the code, the idea still precedes the code. Yes, if you're doing a lot of iterative development, you may change the public interface that testing uses and have to rewrite the tests. That's the biggest problem I have with test-first. But I find it well worth it, because if I were to wait until the code was stable, I'd never have any tests. Test-first encourages me to think about my public interfaces in a good way. -- Peter Scott http://www.perlmedic.com/ http://www.perldebugged.com/ -- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] <http://learn.perl.org/> <http://learn.perl.org/first-response>
