Aristotle, > > But when it comes to testing, doing this in terms of tests is > > not only okay, it's considered best practice. > > No, just intrinsically inevitable, as far as I can tell anyway.
Well, do you agree with this assessment: Having a plan stated as an exact number of tests to be run is a solution to 2 problems. The first is that a test harness must be able to tell when not enough tests have been run. The second is that a test harness must be able to tell when too many tests have been run. Using a success flag at the end of a test script as opposed to a numeric plan solves, equally well, one of those two problems. Since it does not solve the trickier of the two, it is not suitable as a general-purpose solution for all testing. However, since it does solve the more common of the two (the far more common, one might argue), its advantages make it useful, especially for simple test scripts. 'Cause the above is about where I'm at now. For my money, the loss of sense of security you get from the possibility that you might run across one of those uncommon cases and not notice it is about balanced out by the greater likelihood of creating more tests and convincing more programmers to use tests because tests are easier to create and maintain. In fact, I'm starting to sort of view it as a graduated thing: when you're starting out programming, perhaps you use the deferred plan all the time, 'cause it's easy, and when you become more seasoned, you naturally gravitate towards numeric plans for their increased sense of security. And/or, it may make sense to use deferred plans during development, but switch to numeric plans before releasing anything to CPAN. For myself, I think chromatic's warning is strongly making me lean towards the idea that numeric plans are far more useful than I initially gave them credit for, and I personally will probably switch over to numeric plans--at least before I release anything to CPAN, even if I keep using deferred plans for initial development. But as my primary goal right now is to get a team of 3-7 programmers who've been writing tests only haphazardly at best for the past 5-10 years to start writing tests like crazy, I think having deferred plans to KISS is really the way to go. > Overall, I'm reminded of something MJD said in his Program Repair > Shop and Red Flags talk at YAPC::Asia 2007: > > Also I'm trying to get away from right and wrong. This is not > about morals; it's engineering. And so, well, things can be > suboptimal – maybe they aren't designed as well as they could > be –, but they're not wrong, probably. True, I probably overemphasized my frustration on that point. Obviously there _can_ be good reasons to violate the principle, and I figured there probably were in this case. I just wasn't seeing them, then. But now I do. :-) > (The recording is available online, btw, at > <http://video.google.com/videoplay?docid=-4037440245833870135>. > If you haven't seen it, I can only recommend you do. None of it > is surprising in the least for a seasoned good programmer (or so > I'd hope), but it's very lucidly explained.) Cool. I'll have to check that out. Thanx. -- Buddy
