Testing is really super important in a shop that is serious and trying to not waste anyone's time or accidentally ship stuff sideways to customers. Even in the shortest code or whimsical examples like yours, bugs creep in. Proper tests help ensure they don't go unnoticed.

Perl Testing: A Developer's Notebook (ISBN 0596100922) is really quite good. Pick it up. Make your own big projects better and wow the next interview committee. Other required reading: prove, Test::Simple, Test::More, App::Prove. Plenty of other Test:: space to explore as you like.

Here are your tests rewritten (style differences are up to you, I like to omit parens and explicit returns where possible).

use strictures;
use Test::More;
# plan test count here or use done_testing($count).

is hello_world(), "Hello world!",
    "Hello world is hello world";

# Naive test, will not catch your bug, and you have one.
cmp_ok get_number(), ">", 0,
    "get_number() returns greater than zero";

subtest "Iterate on get_number()" => sub {
    my $iterations = 10_000; # Higher confidence.
    my $ok;
    for ( 1 .. $iterations )
    {
        $ok++ if get_number() > 0;
    }
    my $msg = "get_number() returns greater than zero";
    $ok == $iterations ?
        pass($msg)
        :
        fail($msg . " - expected $iterations > 0, got $ok");

    done_testing(1);
};

done_testing(3); # <- Either "plan" or delcare test count here!

exit 0;

sub hello_world {
    "Hello world!";
}

sub get_number {
    int(rand(1000));
}
[download]

~>prove my-test.t -v
ok 1 - Hello world is hello world
ok 2 - get_number() returns greater than zero
    not ok 1 - get_number() returns greater than zero - expected 10000
+ > 0, got 9993
    1..1
not ok 3 - Iterate on get_number()
1..3
Dubious, test returned 1 (wstat 256, 0x100)
Failed 1/3 subtests

Test Summary Report
-------------------
/home/moo/my-test.t (Wstat: 256 Tests: 3 Failed: 1)
  Failed test:  3
Files=1, Tests=3,  0 wallclock secs ( 0.03 usr  0.01 sys +  0.03 cusr 
+ 0.00 csys =  0.07 CPU)
Result: FAIL
[download]

Found your bug, right? int(rand(whatever)) can return zero. Fix with int(rand(1000)+1) and run again.

ok 1 - Hello world is hello world
ok 2 - get_number() returns greater than zero
    ok 1 - get_number() returns greater than zero
    1..1
ok 3 - Iterate on get_number()
1..3
ok
All tests successful.
Files=1, Tests=3,  0 wallclock secs ( 0.03 usr  0.01 sys +  0.03 cusr 
+ 0.00 csys =  0.07 CPU)
Result: PASS
[download]

this was a super response....thanks

The cases you provide are (admittedly) simplistic. When this becomes useful is when you have a method or function, and you want to document what its behavior should be

sub frobnitz { ... }

ok( frobnitz( )                       eq $no_params_results );
ok( frobnitz( @some_parameters )      eq $expected_results );
ok( frobnitz( @some_other_parameters) eq $other_expected_results );
[download]

The comparison can be any type of result that can be tested (does it throw / die, does it set some attribute on an object, etc).

The benefit of this is that you can quickly and consistently check the same behaviors, the same way, every time, after every change, to verify that you have not broken some expected behavior. This is a huge safety net when adding a feature, refactoring, etc. Your tests are, in effect, documentation, in the form of code, that translates English requirements into something that is less prone to misinterpretation more formalized.

thanks....opened my eyes. would you normally have a *.t file for every subroutine? How do you chain tests? (e.g. run t01.t .. t50.t)

App::Prove is a typical harness that is used. Also see make test and build test in the build tool chain.

I have been using (or trying to change my habits to use) Test Driven Development, to minimize the amount of untested code in my codebase. I have been using one .t file per package (well, per .pm file).^*

^* - In reality, I use Test::Class with a unittests.t loader, but that is more of an implementation detail. In effect it is one test file per source file. Test::Class uses inheritance, but I think that test files could also be written using roles.

--MidLifeXis

how do I find the 't' directory for a module?

For any module on CPAN you'll find a consistent layout. Along the top, left-hand side, you'll see:

author_link > distribution_link > module_name
[download]

Follow the distribution link. In the top section of the page now displayed, you'll see Special Files where you'll find a link to MANIFEST (along with quite a few others).

Follow the MANIFEST link. Now you'll see a list of links to all the files that make up the distribution. Scroll down until you find paths like t/xxxx.t. These are all the test files. You can look at the code directly from here: there's no need to download and unpack an entire distribution.

-- Ken

Download it from CPAN, unzip, untar it. The 't' directory does not get installed.

Go to MetaCPAN , click links, find it :)

There are thousands of real-world examples right there on CPAN. You could start with Try::Tiny if you like. I installed the newest version of it about a week ago and therefore know that it uses Test::More.

hth,
Darren

Downloading a substantial CPAN package as-described and looking at its t directory really is probably the very-best source of practical real-world testing voodoo wisdom.

A reall-good test suite works up in stages, from low-level tests of every function of every object including exception cases, to substantially more-complex cases that build on the ones that came before.   You will be amazed at how many bugs you will find in your kitchen when you start looking systematically for them.   But, once they are gone, a test-suite can prove that they still are gone.   There is no substitute for that.