As a matter of style, I would write your test something like this:

use strict;
use warnings;
use Test::More;
my $ntests = 9;
plan tests => $ntests;

{
   my $expected_version = 'v5.32.1';
   cmp_ok( $^V, 'eq', $expected_version, "Version = $expected_version"
+ );
}

{
   my %hash;
   ok( !%hash,                     "Empty: !\%hash"         );
   ok( !scalar(%hash),             "Empty: ! scalar"        );
   cmp_ok( scalar(%hash), '==', 0, "Empty: 0 == scalar"     );
   ok( !keys(%hash),               "Empty: ! keys"          );

   ++$hash{entry};
   ok( (%hash ? 1 : 0),            "Not empty: \%hash"      );
   ok( scalar(%hash),              "Not empty: scalar"      );
   cmp_ok( scalar(%hash), '!=', 0, "Not empty: scalar != 0" );
   ok( (keys(%hash) ? 1 : 0),      "Not empty: keys"        );
}
[download]

Some points to note:

• I always prefer Test::More to Test::Simple because that scales better as test scripts grow more complex over time.
• At the top of your test script, you should explicitly declare how many tests your script intends to run, to protect against premature failure. I always use plan for this because as test scripts grow more complex over time you sometimes need to calculate this number.
• I pulled a face the instant I saw your &ok() function calling style! Haven't seen that dreadful old style for 20 years! :) From Perl Best Practices: Call subroutines with parentheses but without a leading & (item 113). Update: see also.
• Minimize the scope of variables. I find bare blocks a convenient way to do this in test scripts. Just because it is a test script doesn't mean you should drop basic standards of code quality.
• Prefer cmp_ok to ok because you get clearer diagnostics when a test fails (see below for an example).
• Don't repeat yourself. Test scripts are programs and you should follow the same coding quality standard in the test scripts as for the code under test. Doing this makes long term code maintenance more enjoyable and less error-prone.

When I first ran your test script, it failed with:

not ok 1 - Version = v5.32.1
#   Failed test 'Version = v5.32.1'
#   at badtests1.pl line 8.
[download]

Note that using cmp_ok instead of ok provides clearer diagnostics:

#   Failed test 'Version = v5.32.1'
#   at badtests2.pl line 9.
#          got: 'v5.32.0'
#     expected: 'v5.32.1'
[download]

See Also

• Basic Testing Tutorial by hippo
• Re: Winning people over to better development practises (TDD)

• Re: I need perl coding standards (Coding Standards References)
• Effective Automated Testing

---

---

Posts are HTML formatted. Put <p> </p> tags around your paragraphs. Put <code> </code> tags around your code and data!

Titles consisting of a single word are discouraged, and in most cases are disallowed outright.

Read Where should I post X? if you're not absolutely sure you're posting in the right place.

Please read these before you post! —

• How do I compose an effective node title?
• How do I post a question effectively?
• Markup in the Monastery

Posts may use any of the Perl Monks Approved HTML tags:

a, abbr, b, big, blockquote, br, caption, center, col, colgroup, dd, del, details, div, dl, dt, em, font, h1, h2, h3, h4, h5, h6, hr, i, ins, li, ol, p, pre, readmore, small, span, spoiler, strike, strong, sub, summary, sup, table, tbody, td, tfoot, th, thead, tr, tt, u, ul, wbr

You may need to use entities for some characters, as follows. (Exception: Within code tags, you can put the characters literally.)

	For:		Use:
	&		&
	<		&lt;
	>		&gt;
	[		&#91;
	]		&#93;

Link using PerlMonks shortcuts! What shortcuts can I use for linking?

See Writeup Formatting Tips and other pages linked from there for more info.