Slash Boxes
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 ]

Matts (1087)

  (email not shown publicly)

I work for MessageLabs [] in Toronto, ON, Canada. I write spam filters, MTA software, high performance network software, string matching algorithms, and other cool stuff mostly in Perl and C.

Journal of Matts (1087)

Wednesday January 12, 2005
08:20 AM


[ #22676 ]

Following on from chromatic's journal entry about quieter tests I thought I'd make a full journal post about Test::Verbose.

If you test, you need Test::Verbose.

The simple "tv" command line it installs will run all your tests, some of your tests, or an individual test. Unlike "prove" it is an interface to "make test" rather than a separate script for running tests, so if you make changes you don't need a separate "make" phase to get things into blib.

More importantly though is you can run tv with the -q option to make it only display errors, -qq to make it only display the final results table, or -qqq to make it display nothing at all (but exit with a relevant return code). This last option makes it perfect from cron job smoke tests.

Try it out today. You won't go back.

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
More | Login | Reply
Loading... please wait.
  • It does require a makefile, no?

    I don't have that for my applications. A typical directory structure looks like this:



    The .t files contain a 'use lib "lib", "../lib";' to point to the module directory.

    Like chromatic I usually just type perl t/FILENAME to run a certain test file, but I

    • You would have one Makefile.PL with a very simple contents:
      use ExtUtils::MakeMaker;
          NAME => 'projectname',
          AUTHOR => 'me',
          VERSION => '1.0',
          ABSTRACT => 'this is my project',
      You can change a few of those to extract better info, but you don't really need it.

      ExtUtils::MakeMaker will find all your .pm files under a lib/ directory.
  • prove is now standard with Test::Harness and Perl itself. I'd rather that people start/keep using it.


    • But prove doesn't do the same thing. It doesn't call "make test", and since it has been designed not to call "make test", it very likely won't every be changed to do so by default, right?
      • I'm ignorant: why is that better?
        • Because with prove my t files have to contain "use lib 'lib';" in order to see changes in my lib directory, and that could cause odd errors if you're not very careful (overriding a blib directory that you don't expect it to do).
          • See [] for the handling of this.

            And, if it doesn't do what you want, ask. :-)



            • It doesn't do what I want. I want something that runs "make test".

              What if my files aren't just in lib/, but are in completely separately named directories, each with their own Makefile.PL - MakeMaker picks this up and gets everything into blib, but prove won't see them.

              See XML::Parser for an example of this.
              • OK, that's not going to work then. :-)

                The #1 reason to have prove is so that you don't have to have a Makefile or run make test at all. So in this case, it would defeat the purpose of running prove.

                Is there anything we can/should add to Test::Harness to make it more useful to you?



        • Andy updated prove a while back at the request of David Wheeler and myself with an option to include the local lib directory.
          -l, --lib       Add lib to the path for your tests.
          MyModule$> prove -lv t/.*t
          will run all test files in t/ with lib/ included in @INC.