use Perl

• stdout v stderr (Score:1)

  by jmason (3282)

  I tend to use "classic" Test, which can still do the "silencing extra diagnostics" trick; just output the extra diagnostics on STDOUT, and keep STDERR for serious stuff (and perl warnings, of course).
  
  when run from "make test" or "prove", the STDOUT output is hidden; when run from "make test TEST_VERBOSE=1" or "prove -v", or run directly from the commandline as "./testname.t", the STDOUT diagnostics become visible.
  
  works great ;)
  • Re: (Score:2)

    by Ovid (2709)

    I tend to use "classic" Test ...

    Do you mean the ancient Test.pm? If so, you're missing out on all of the improvements made in the testing world over the years. Test.pm should only be there for legacy support.

    If you must use that interface, at least consider using Schwern's Test::Legacy [cpan.org] module. This will allow you to keep that interface but still use other testing modules. Of course, that changes your diagnostic output and breaks what you've described. However, diagnostics are a small, small price to pay for using the rest of Perl
    • Re: (Score:1)

      by jmason (3282)

      yeah, I do mean that ancient module. and I know there are many goodies available if I was to catch up ;)
      
      In SpamAssassin, we have a project philosophy of attempting to keep our CPAN dependencies at a minimum, and we support perl 5.6.1 as a platform. even Test::More didn't arrive until 5.6.2, unfortunately...
      
      I should really use Test::More for my other modules, though.
      
      'Of course, that changes your diagnostic output and breaks what you've described.'
      
      really? are you saying the newer test modules remove this (v
      • Re: Test::More and backcompat (Score:1)

        by markjugg (792)

        In SpamAssassin, we have a project philosophy of attempting to keep our CPAN dependencies at a minimum, and we support perl 5.6.1 as a platform. even Test::More didn't arrive until 5.6.2, unfortunately...

        Assuming you have a compatible license, you can do what the darcs project does: Ship a private copy of Test::More with the test suite suite. This eliminates problems between your test suite and different versions of Test::More as well.
• Adding to the output though... (Score:1)

  by jjore (6662)

  I've been foraging for good ideas in Squeak/Smalltalk lately. One nice thing is that test failures have a stack saved so I can pop up the relevant process in the debugger/IDE wherever and whenever things fail.
  
  I've been considering how well this could map to perl - whether a test failure should save the stack so tools could know exactly what was around. I'm not sure whether Perl is powerful enough to ever make use of this information. ATM, it's speculation.
  • Re: (Score:2)

    by Ovid (2709)

    You know, you might want to chat with Andy Armstrong. He's been toying with the idea of creating a reversible debugger for Perl. As I understand it, it's similar in concept to how video works: occasionally save the state (a "key frame") and save then a bunch of diffs until you need to save the state again. With that, you could just note the "time" of the test failure and persist its state. You could then reverse to a previously known state, change parameters, run things forward again, etc.