use Perl

• Testing (Score:2)

  by davorg (18)

  turning Perl into the most testable platform on the planet

  This is an excellent point. I wonder if anyone has used Perl's new improved testing features to persuade their bosses to use Perl over some other language.

  How do other languages stack up against Perl in testability?
  • Re:Testing (Score:2)

    by djberg96 (2603)

    Ruby's Test::Unit [talbott.ws] (by Nathanial Talbott) works well. I haven't used either one very extensively, but I think they're about on par with each other. I've used it to help me catch some bugs while porting Spreadsheet::WriteExcel.

    Someone feel free to disagree...
    • Re:Testing (Score:2)

      by Matts (1087)

      I don't want to disagree, but I still think Ruby has a long way to go in this respect. It still has no unified build framework (unless this has changed recently), and since it doesn't have the above, I'm assuming it doesn't have a unified test harness framework.
      
      While ruby's Test::Unit looks vaguely interesting, it doesn't look nearly as simple as Test::Harness + Test.pm (or Test::More). The thing about Test::Harness is that it's not a module, but a tool. And a nice tool at that - it shows me test progress,
      • Re:Testing (Score:1)

        by perigrin (3495)

        Yes, but don't we all just want CPAN for [insert non-perl lanugauge here]?
• If you like is_deeply, see also Test::Differences (Score:1)

  by barries (2159)

  Even real tigers prefer ir to meat.
• See also Test::More's no_plan option (Score:1)

  by barries (2159)

  For testing with a variable number of tests.
• Graphical test failure hotspot diagrams (Score:1)

  by barries (2159)

  And here's a neat page that shows how to map out your code coverage for failing and passing tests to show code that is likely to be involved with failed tests:

  http://www.cc.gatech.edu/aristotle/Tools/tarantula/ [gatech.edu]

  Now, when I break a test, I usually know what I changed, so I'm not sure how useful this is for me. For the automated perl smoke tests, it could be cool, though the profiling bit would slow the tests down a lot.

  Anyway, just some cool stuff. See the related work on that site about using antia
• Planning (Score:1)

  by Dom2 (2981)

  But the syntax you gave is exactly the syntax for plan under Test::More:

  use Test::More;
  
  opendir( D, '/etc' ) or die $!;
  my @files = grep { -f } readdir( D );
  
  plan tests => @files;
  
  # ...

  See, nice and simple. No BEGIN blocks required. And, as somebody else mentioned, there's always no_plan if you're feeling lazy.

  -Dom
• Test::More (Score:2)

  by Ovid (2709)

  Have you considered using Test::More? It has much more useful testing facilities and it allows you to name tests, which can give you very descriptive testing information. Further, if a test fails, it often provides very useful diagnostic information such as telling you what value you were expecting in $foo and what value $foo actually received. Here's a sample from some tests of a "People" object that I have.

  #
  # testing is_senior_contact()
  #
  
  $sql = <<"END_SQL";
  SELECT people_id, category_id
  FRO