My suggestion is to write more tests and label them very well. Then use prove -vb to run them when you want to see all the detail. Another good approach is to use diag but only when a test fails:

is( $thing->foo(), 42, "foo is 42" ) or diag $thing->as_string();
[download]

More generally, you may want to rethink your testing structure (or even your module structure). Personally, I like to do test-driven development. I write the tests first for each function, defining the expected outputs for a range of valid inputs to each argument. That lets me play-test the API up front. If I hate the API as I write the tests, I can refine it before I've even coded anything. Then I code it and make sure it works. Then I write tests for how the function handles invalid inputs.

This may seem like a lot of work, but it doesn't have to be if you put your inputs and outputs in a data structure and let your tests run in a simple loop. I elaborate a bit on this in Re^2: Wanted, more simple tutorials on testing.

If you feel that there are too many possible outputs to test them all, you may need to break your function down into several smaller units, each of which is easier to test. If you feel you need to trace what's happening in the middle of your code, that might be a warning sign that you're testing at too high a level.

If I still can't figure out why a test isn't working from examining the output of a function that is failing a test, that's when I use the debugger to jump to that part of my test script and then step through it. Sadly, prove doesn't make it easy to run the debugger</c>. You have to set an environment variable:

HARNESS_PERL_SWITCHES="-d"
[download]

Alternatively, if you're using ExtUtils::MakeMaker or Module::Build, they will set it for you:

$ make testdb TEST_FILE=t/mytest.t          # ExtUtils::MakeMaker

$ Build testdb --test_files t\02_trivial.t  # Module::Build
[download]