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

use Perl Log In

Log In

[ Create a new account ]

petdance (2468)

petdance
  andy@petdance.com
http://www.perlbuzz.com/
AOL IM: petdance (Add Buddy, Send Message)
Yahoo! ID: petdance (Add User, Send Message)
Jabber: petdance@gmail.com

I'm Andy Lester, and I like to test stuff. I also write for the Perl Journal, and do tech edits on books. Sometimes I write code, too.

Journal of petdance (2468)

Friday November 07, 2003
03:51 PM

New testing tool in Test::Harness 2.32

[ #15647 ]
I've uploaded the new Test::Harness, version 2.32. (Also available at the PAUSE FTP site if it's not updated yet on search.cpan.org)

Test::Harness now comes with a command-line utility called prove that runs tests against the harness. Why have a separate utility? What's wrong with "make test"?

prove has a number of advantages over make test when doing development.

  • prove is designed as a development tool
  • Perl users typically run the test harness through a makefile via make test. That's fine for module distributions, but it's suboptimal for a test/code/debug development cycle.

  • prove is granular
  • prove lets your run against only the files you want to check. Running prove t/live/ t/master.t checks every *.t in t/live, plus t/master.t.

  • prove has an easy verbose mode
  • To get full test program output from make test, you must set HARNESS_VERBOSE in the environment. prove has a -v option.

  • prove can run under taint mode
  • prove's -T runs your tests under perl -T.

  • prove can shuffle tests
  • You can use prove's --shuffle option to try to excite problems that don't show up when tests are run in the same order every time.

  • Not everything is a module
  • More and more users are using Perl's testing tools outside the context of a module distribution, and may not even use a makefile at all.

I welcome your comments and suggestions about prove, and I hope you find it as useful as I have over the past couple years of development.

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.
  • Only question, why prove? I might have expected runtests or testrun or some such. Too bad test is taken.

    -sam

    • I knew I shoulda put a section called "Why prove?" in the docs. :-)

      First, test was right out, even if it wasn't already taken. It's one of those words that when I see it as a file I assume is garbage, like temp or foo. runtests is 8 characters, and it's two words. I wanted a single word. The program started as smoke at my day job, but smoke already has a meaning to Perl, or at least to the people who run the builds.

      So I had to have a single word, and I convened an impromptu brainstorming session i

      --

      --
      xoa

    • Heh. taken would be a great name.

      "Why is it called taken?"
      "Because test is taken."
      --
        ---ict / Spoon
  • We often need to pass environment variables to our tests to simulate a particular run environment. We also tend to have logic wrapped around these variables to set parameters for sandbox testing, QA testing, etc.

    Would it be possible to pass something into prove to make it run some pre-test code? If given a certain flag, maybe have it look for a default config-type file in the current directory and require it before running?

    Just a thought...thanks for the new tool!
  • I've already found this useful. using "make test", it was hard to remember the syntax to run just some particular tests and be verbose about something. This made it easy to re-test a particular script for DBD::Pg:

    prove -v -Iblib/lib -Iblib/arch t/01setup.t t/15table_attrs.t t/99cleanup.t