|The stupid question is the question not asked|
Yes, prove sucks. A lot. I recall it not sucking this bad. The "summary" output is way too verbose and yet almost everything in the summary is useless (and much of it is just purely incorrect). Meanwhile, it is doing a great job of hiding from the user what would be less output but that would be extremely informative.
What's worse, the current implementation of prove is like some doctoral thesis on how to over-engineer software using rampant application of inheritance, factories, and "pure" layers of abstraction (that appear to have no use other than adding layers of abstraction). And this makes it extremely time-consuming to find the bit of code that is at fault each time I go to make a tiny improvement to it.
Trying to follow the flow of prove's code, you repeatedly get the impression that extreme effort was exerted for the sole purpose of making it difficult to follow the code flow.
You get to a promising-sounding class only to find it has no code that does anything real at all. It just contains a method called 'run' that does nothing other than call a method called 'next' on something else. So you go to find where that something was created so you can know the class name so you can go read the code for that class to see what the 'next' method does. But the code that creates that "something else" is a factory where the class name used is derived via complex means hidden under several layers of abstraction.
After spending a significant amount of time trying to navigate those several layers of abstraction, you finally come up with another promising-sounding class name. So you go read the code for it and you even find a 'next' method. Unfortunately, all it does is dereference a code reference that was created by some other code. Now you don't even have a method name to aid your next search step.
Now I've spent an hour or two trying to just find what is surely a very simple couple of lines of Perl code that I'm sure I could fix in a matter of minutes because the specific problem I'm trying to address is a very simple problem, but I don't get three hours of uninterrupted time at work hardly ever so I have to go to a meeting or help somebody with some issue and after that, the dozens of layers of pure abstraction have mostly fallen out of my head and I'm nearly starting over from the beginning if I want to look for the needle of functional, practical code in the haystack of dozens of pure abstraction layers.
I think I'll next just install an old version of 'prove' and see if the output is tons more useful (like I remember). If not, at least I can tell from the much shorter list of modules that are included (and the fact that these modules have practical-sounding names rather than names that sound like theoretical abstraction layers) that I'll be able to make fixes without needing hours and hours of time to fill my head with dozens of pure layers of abstraction.
(At least none of the layers are (yet) hiding behind a truly enormous pile of code like if they started using Moose... *shudder*)