On 19/07/06, chromatic <[EMAIL PROTECTED]> wrote:
On Wednesday 19 July 2006 10:01, Fergal Daly wrote:
> Let me rephrase that. What's wrong with the author's expectation that
> he can use the his standard programming toolkit and get sensible
> results?
>
> Something is broken but I don't see why it must be the test script.
Perhaps then the expectation that people read the documentation?
A correctly documented bad user experience is still a bad user
experience. What possible justification is there for not being able to
easily use subroutines in test scripts?
> Also, if my_ok runs 2 tests then there's no way to tell them apart
> because they'll both be attributed to the line that calls my_ok().
See point 2 about what's broken in that code then. You have the same problem
if you replace the subroutine with a loop. Strangely, that doesn't increase
the number of stack frames.
Absolutely, I've used the loop example already for why test names are
good. It's also an example for why nested blocks are good. Each run of
the loop is a block with a name (or a number if you're nomophobic) and
each test in the loop is a subtest of a block.
> > That's a *lot* of information to vomit for a failing test. How easily
> > can you pick out the right call frame out of ten or more?
>
> 10 lines? There's only 1 sub call, so that's 2 lines.
Please post your magic incantation which can magically pick (through
appropriate magic) the magical point at which it can cull stack frames, being
able to determine, somehow -- perhaps with magic? -- the point at which to
report the ultimate point of decision for the test. Magically.
I tease, but that's because I think there's no good general heuristic that can
possibly work here.
It's already done! Test::Builder already knows how to find where the
user script jumps into Test::XXX land. All I'm saying is that instead
of just outputting that 1 frame, output all the frame from there on up
(in this case 2). Neither magic nor rocket science.
If there's a better heuristic, great. If there's an easier way than that
local blah blah mess, wonderful! I'd love to see either or both of those. I
haven't, and I don't think a full stack trace is useful and I really don't
think you can prune a partial stack trace to be useful.
I'm not proposing elminating the local $blah stuff from Test::XXX
modules, just making it possible for users to get sensible messages
even if they use subroutines in their test scripts.
> Extra boilerplate code just to be able to use subroutines is an issue
> (especially when it's this verbose),
When comparing one extra line for the test writer versus a dozen or more extra
lines for each failure for every person who runs the test, my math says "Hm,
the test writer can take that one."
See above for why there is no dozen lines,
F
