On Jan 22, 2009, at 5:22 PM, Michael G Schwern wrote:
Because, in Perl and other languages, until you run it you can't
know what
class $object is going to be, or what its inheritance tree will look
like, and
once you do figure out which run_tests() will run (if any) you're
back to the
problem of figuring out how many tests are in run_tests().
I'm in complete agreement with you here, but just to clarify something
that became clear to me only when Eric and I discussed it on IRC, what
Eric is thinking of is basically turning a loop of unknown length into
a single test. So to use your examples, it would be:
test {
for my $thing (@things) {
is $thing, "something";
}
}
Somehow, in this example, the `is` would be a subtest, and therefor
uncounted. The call to test() is a single test.
Personally, I think this is a bad idea, because I *want* to count how
many tests are run for @things. But what Eric seems to be talking
about is some kind of subtest, AFAICT.
If we were using a mathematically provable functional programming
language,
say Haskell, there are some cases where you can do static analysis
and figure
out how many tests are going to run. If you got really clever I'll
bet you
could do it for most cases. But when a test involves any randomness
or
outside input it is impossible to know. The best you can do is know
when you
can not know.
Yeah, I think Eric is thinking that "those bits with randomness would
be counted as only one test, run in a call to `test {}`.
Best,
David
