Stuff with the Perl Foundation. A couple of patches in the Perl core. A few CPAN modules. That about sums it up.
It's just a minor change that both Andy and I have wanted for a long time, but I do wonder if it will impact others. Instead of seeing this (use.perl inserts extra spaces, so this might not line up right):
t/proverun......................ok
t/regression....................ok
t/result s.......................ok
t/scheduler.....................ok
t/source........ ................ok
t/spool.........................ok
t/state................. ........ok
t/streams.......................ok
You'll see this:
t/proverun
.................... ok
t/regression.................. ok
t/results..................... ok
t/scheduler................... ok
t/source...................... ok
t/spool....................... ok
t/state....................... ok
t/streams..................... ok
Both of us found this much cleaner. However, this might have unexpected consequences. It also highlights the issue of Test::Harness's long-standing practice of stripping the
not a problem for CPAN::Reporter (Score:1)
What do you do if the test file name is longer than your fixed column width?
t/something/something-else/with-a-long-long-long-long-test-name.t
-- dagolden
Re: (Score:2)
The width of the reporting is based on the width of the test names, so it expands as needed.
Re: (Score:1)
Re: (Score:2)
We don't worry about that. If you prefer a different format, you're welcome to subclass :)
Re: (Score:1)
Re: (Score:1)
And Yes, apparently I'm full of piss and vinegar today. Maybe this is what happens when I drink coffee. :-)
Re: Test::Harness ouput change (Score:1)
While we are on the topic of Test::Harness output, a change that I'd like to see is padding of the test number so that test comments are aligned.
For example consider the following trimmed down test program and output:
Re: (Score:2)
I like this thought because things which improves comprehension are good, but there are a couple of issues here. First, many test descriptions (what you're referring to as a comment), are often close to the width of whatever terminal I'm working with, so pushing them out even further may be problematic. Second, since we don't always know up front how many tests will be run, we won't know what padding would be needed.
However, rather than a specific solution like this, how about a more general one?
Re: (Score:1)
You could generate a test message with this format and try to parse it and see that the parts all where you expected them. (Should the parts be randomly generated so the user can’t fool you?) If that fails you tell the user that their format is no good and bail.
Re: (Score:1)
Ah, no, there is a simpler way, which is to try twice, with messages that differ in all parts.
Looks nice. (Score:2)
I like it.