Recently I was required to create another flavor of test harness that
runs tests, then captures and stores output.
The nature of my testing means that I am running millions of tests,
and the resultant captured output is therefore huge. So I modified
my tests to do the *equivalent* of the f
> I'm with Adrian. Printing out "ok" 100,000 times shouldn't be a
> big deal unless you're reading the TAP via some sort of IP over
> clay tablets protocol. But...
My test estimate is two orders of magnitude larger, so it actually is
a big deal to capture and store those results.
But I woul
> and waiting for the test output/TAP to be parsed takes quite a while.
> Just my $0.02 worth.
> -=Chris
To each his own, but my thoughts were not that it takes time to
parse, or that there is any unreasonable performance issue here -
just that it is so completely *unnecessary* to say "ok" lo
> This raises the question, why are you storing the raw results
rather than
> storing the results after having been run through a TAP parser?
I am storing all test results, from all test runs, to drive a
tinderbox report with drill-down capability. I can (and do) post-
process the TAP outpu
I'm wanting sparse output:
1..100 sparse
12 not ok
83 not ok
Which is three lines of output, instead of 97, but contains the same
information as:
1..100
1 ok
2 ok
...
12 not ok
...
83 not ok
84 ok
