2009/1/22 Eric Wilhelm <scratchcomput...@gmail.com>: > # from Andy Lester > # on Thursday 22 January 2009 11:35: > >>> Perhaps I'm being unclear. I do not find either 'no_plan' or 'plan' >>> to be useful in their current state. >> >>Yes, but many others do. > > Well, are we just accepting limitations and refusing to dream? > > <ewilhelm> the computer must use a $number. does the *human* actually > want to use a $number? > <Theory> This human does. > <soh> i do. i always want to know if more tests than i expect are > running > <Theory> Because the computer can get it wrong. > <ewilhelm> no, the computer doesn't get things wrong > <Theory> It does because of loops. ... > <ewilhelm> ok, so everybody who likes to manually set a static number > just doesn't *trust* the computer? > <Theory> Correct. > > If we were to pretend that tests could be declared in such a way that a > plan could be derived from static analysis and perhaps a bit of startup > computation, would there be any reason to do otherwise? > > If the answer is yes, please explain how the reason does not cite a > limitation of the implementation.
Assuming the static analysis was correct, it would always produce the correct number thus would be equivalent to no_plan. For me, the purpose of the plan is not to detect failures that cause early exits - it can do that but the test harness also looks at exit codes etc. The purpose of the plan is to ensure that the test I just added really do run. I am not terribly happy with plans as they currently exist, loops make them a bit of a pain, I'd really like to be able to have blocks with subplans etc to ease that but I'm not going to start on that again. The point is that plans are a checksum, making sure that the test script you wrote tests as many things as you think it does. Having spent most of the last 5 years using python and pyunit I have missed plans and have once or twice been bitten by tests that weren't actually being called and a plan would have saved me, F > Thanks, > Eric > -- > The only thing that could save UNIX at this late date would be a new $30 > shareware version that runs on an unexpanded Commodore 64. > --Don Lancaster (1991) > --------------------------------------------------- > http://scratchcomputing.com > --------------------------------------------------- >
