Michael Schwern wrote: > Ah HA! I've been wondering why nobody ever thinks to write a simple > ok() function for their tests! perlhack has bad testing advice. Could you explain the advantage of having a "simple ok() function"? As somebody who has spent many painful hours debugging test failures, I'm intimately familiar with the _disadvantages_. When you run the test, you know that "test 113 failed". That's all you know, in general. It's bad enough having to count the ocurrences of the ok() function to find out *which* test failed; and it's made considerably worse when, as is often the case, some of the ok()s are in loops. When tests are written in the naive style, life is much simpler. A simple "/ok 113" in vi will usually suffice to locate the offending test. Even if the failing test is in a loop, it's easy to tell what range of test numbers are encompassed by a particular loop. The "simple ok() function" may make test scripts easier to write, but it makes them a *lot* more difficult to use. One compromise would be to use a test-generating script, which allows the tests to be structured simply and _generates_ the actual test code. One could then grep the generated test script to locate the failing code. .robin.