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? > 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. > > 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. 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. > 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." -- c
