|Welcome to the Monastery|
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
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.
Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
"Science is about questioning the status quo. Questioning authority".
In the absence of evidence, opinion is indistinguishable from prejudice.