use Perl

• not a problem for CPAN::Reporter (Score:1)

  by dagolden (6584)

  CPAN::Reporter ignores that and just looks for the grade at the end, so green light from me.
  
  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)

    by Ovid (2709)

    The width of the reporting is based on the width of the test names, so it expands as needed.
    • Re: (Score:1)

      by jk2addict (4946)

      And when that gets past 72/80?
      
      
      • Re: (Score:2)

        by Ovid (2709)

        We don't worry about that. If you prefer a different format, you're welcome to subclass :)
        • Re: (Score:1)

          by jk2addict (4946)

          Good. Now I can finally stop sticking to 72/80 in my perl source files too. Use a different editor/console! :-)
          • Re: (Score:1)

            by jk2addict (4946)

            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)

  by jmcnamara (659)

  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:

  use Test::More tests => 11;
  
  for (1 .. 11) {
      is(1, 1, 'This is a comment');
  }
  
  __END__
  
  perl output1.t
  1..11
  ok 1 - This is a comment
  ok 2 - This is a comment
  ok 3 - This is a comment
  ok 4 - This is a comment
  ok 5 - This is a comment
  ok 6 - This is a comment
  ok 7 - This is a comment
  ok
  • Re: (Score:2)

    by Ovid (2709)

    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?

    prove -r
    • Re: (Score:1)

      by Aristotle (5147)

      There’s not much we could do to stop that

      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)

        by Aristotle (5147)

        Should the parts be randomly generated so the user can’t fool you?

        Ah, no, there is a simpler way, which is to try twice, with messages that differ in all parts.
• Looks nice. (Score:2)

  by schwern (1528)

  I like it.