| This lab introduces the most basic features of Test::Simple , the simplest testing module. You'll see how to write your own test for a simple "Hello, world!"-style program. How do I do that? Open your favorite text editor and create a file called hello.t . Enter the following code: #!perl use strict; use warnings; use Test::Simple tests => 1; sub hello_world { return "Hello, world!"; } ok( hello_world( ) eq "Hello, world!" );
Save it. Now you have a simple Perl test file. Run it from the command line with prove : $ prove hello.t
You'll see the following output: hello....ok All tests successful. Files=1, Tests=1, 0 wallclock secs ( 0.09 cusr + 0.00 csys = 0.09 CPU)
What just happened ? hello.t looks like a normal Perl program; it uses a couple of pragmas to catch misbehavior as well as the Test::Simple module. It defines a simple subroutine. There's no special syntax a decent Perl programmer doesn't already know. The first potential twist is the use of Test::Simple . By convention, all test files need a plan to declare how many tests you expect to run. If you run the test file with perl and not prove , you'll notice that the plan output comes before the test output: $ perl hello.t 1..1 ok 1
The other interesting piece is the ok( ) subroutine. It comes from Test::Simple and is the module's only export. ok( ) is very, very simple. It reports a passed or a failed test, depending on the truth of its first argument. In the example, if whatever hello_world( ) returns is equal to the string Hello, world! , ok( ) will report that the test has passed.
Note: Anything that can go in an if statement is fair game for ok( ) .
As the output shows, there's one test in the file, and it passed. Congratulations! What about...
Note: In some cases, the number of tests you run is important, so providing a real plan is a good habit to cultivate .
| Q: | How do I avoid changing the plan number every time I add a test? | | A: | Writing 'no_plan' on the use line lets Test::Simple know that you're playing it by ear. In this case, it'll keep its own count of tests and report that you ran as many as you ran. #!perl use strict; use warnings; use Test::Simple 'no_plan'; sub hello_world { return "Hello, world!"; } ok( hello_world( ) eq "Hello, world!" );
When you declare no_plan , the test plan comes after the test output. $ perl hello.t ok 1 1..1
This is very handy for developing, when you don't know how many tests you'll add. Having a plan is a nice sanity check against unexpected occurrences, though, so consider switching back to using a plan when you finish adding a batch of tests. | | Q: | How do I make it easier to track down which tests are failing? | | A: | When there are multiple tests in a file and some of them fail, descriptions help to explain what should have happened. Hopefully that will help you track down why the tests failed. It's easy to add a description; just change the ok line. ok( hello_world( ) eq "Hello, world!", 'hello_world( ) output should be sane' );
Note: Having tests is good. Having tests that make sense is even better .
You should see the same results as before when running it through prove . Running it with the verbose flag will show the test description: $ prove -v hello.t 1..1 ok 1 - hello_world( ) output should be sane
| | Q: | How do I make more detailed comparisons? | | A: | Don't worry; though you can define an entire test suite in terms of ok( ) , dozens of powerful and freely available testing modules work together nicely to provide much more powerful testing functions. That list starts with the aptly named Test::More . | |
