Re: An alternate view on deferred plans

2008-03-30 Thread Aristotle Pagaltzis
* Buddy Burden [EMAIL PROTECTED] [2008-03-29 20:55]: I just think that having code where every time you change things in one place, you have to make sure you change something somewhere else isn't a good thing. In any other programming scenario, I think most everyone would agree with me. I

Re: An alternate view on deferred plans

2008-03-30 Thread Buddy Burden
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

Re: An alternate view on deferred plans

2008-03-30 Thread chromatic
On Sunday 30 March 2008 14:57:35 Buddy Burden wrote: And/or, it may make sense to use deferred plans during development, but switch to numeric plans before releasing anything to CPAN. That's what I do. I have a pair of Vim macros which toggle my plans. -- c

Re: An alternate view on deferred plans

2008-03-30 Thread Aristotle Pagaltzis
Hi Buddy, * Buddy Burden [EMAIL PROTECTED] [2008-03-31 00:05]: 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

Re: An alternate view on deferred plans

2008-03-30 Thread Michael G Schwern
Aristotle Pagaltzis wrote: Note that it doesn’t quite protect you from running too few tests either. You may botch some conditional in your test program and end up skipping tests silently, in which case you will still reach the `all_done()` line, and it’ll look as if all was fine. The typical