Not me. Whilst the 'tests first' brigade are writing tests to see if Perl remembers how to load a module, detect a non-existent or privileged file, and hasn't forgotten how to do math, I'll be writing an* application that uses the module.

Functions/methods within that module will simply return reasonable constant data/predefined status until the application is written, compiles and runs. Once the application runs, then I start filling in the bodies of of those APIs one by one, checking the application continues to run correctly as I go. Adding asserts in the APIs to check parameters. And asserts in the application to check returns.

I find it infinitely preferable to have the application or module die at a named line, of a named file, so that I can go directly to the failing assertion, than to

• sit and watch streams of numbers, dots and percentages scroll off the top of my screen.
• And then have to re-run the tests and pause/abort it to find the name of a .t file and some imaginary number.
• Then go find that .t file and try and count my way through the tests to find which one failed.
• Then try and work out what output the test actually produced that didn't match the expected output.
• Then try and relate that to something in the module that failed to work as expected.
• Then go find the appropriate line of the module.

And that's the abbreviated version of many of the test failures I've had reported by modules using the Test::* philosophy.

A test should be located as close as possible to the point of failure--and tell me what went wrong and where. Anything else is just mastication.

*An, not (necessarily) the application. A contrived and simplified sample that exercises the full API, is fine. It can also act as user documentation/sample code.