Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • Excuse my ignorance on what features you already have...

    Does this thing have URI support yet?

    Can I say "Go test that URL that will spit you back TAP" and have it work?
    • by Ovid (2709) on 2007.01.04 4:45 (#52579) Homepage Journal

      This feature is not yet ready but I'm already getting email asking for it so I need to see if I can get this out the door by this weekend at the latest. My biggest obstacle, actually, isn't getting this feature to work (it's fairly simple), but getting TAPx::Harness output as similar as possible to Test::Harness output. I don't want to suprise users too much by making the output radically different, but I also have so much more information I can present, if they users want it (such as which tests unexpectedly succeeded), that the output has to be different in some ways.

      On the off chance you were asking a different question, here's a more complete description of the rationale and implementation.

      In Schwern's original plan for this [yi.org], he wanted to have a bunch of separate "source" modules:

      • TAP::Harness::Source::String
      • TAP::Harness::Source::PerlDotT
      • TAP::Harness::Source::HTMLValidator
      • TAP::Harness::Source::HTTP
      • TAP::Harness::Source::Executable
      • ... and so on

      You can go back to that link and see what he was thinking, but I've realized that the bottleneck in that approach is that most end users are going to wait for someone else to write a TAP::Harness::Source::... module for their particular needs rather than write it themselves. Or such a source module will already have been written but it's features will be too limited. My approach allows you to write a simple test program which takes an input and figures out how to test it. For example:

      #!/usr/bin/perl

      use Test::More tests => 4;
      use Test WWW::Mechanize;

      my $mech = Test::WWW::Mechanize->new;
      my $url  = shift;
      $mech->get_ok(
        $url,
        "We should be able to fetch ($url)"
      );
      $mech->title_like(
        qr/^Login to control panel for/,
        "... and page should be a customer control panel login page"
      );
      $mech->content_like(
        qr/Copyright 2007 by Acme Corp/,
        '... and it should have our copyright'
      );
      $mech->page_links_ok("... and links from this page should be good");

      Then you just use any of a variety of methods to pass a list of URLs to it. One of the simplest, if you name the above program test_control_panel_logins:

      runtests 'test_control_panel_logins' < list_of_control_panel_urls.txt

      Thus, as long as you can figure out how to write a test for something, you could use runtests to test anything.