<br>Another thing I'd suggest is to NOT use the last argument of ok() as a label.<br><br>The message argument of all those test functions is only displayed if there's something wrong, if the test fails.<br><br>It's most useful if the message tells you what failed.  For example, instead of <br>

<br>ok( open(my $fh, "> logfile"), "open logfile succeeded");<br><br>this would make more sense, since the message only shows if the test fails:<br><br>ok( open(my $fh, "> logfile"), "open logfile failed: $!" );  # open should succeed<br>

<br>So, instead of the error message "open logfile succeeded" showing, 
which is confusing because it actually didn't succeed, the message "open
 logfile failed: no space on filesystem" shows, which is better.<br>
<br>The expectation is open should succeed.  If it fails, the message is displayed with the error reason.<br><br><br><div class="gmail_quote">On Sat, Mar 3, 2012 at 10:18 AM, Rob Janes <span dir="ltr"><<a href="mailto:janes.rob@gmail.com">janes.rob@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">another thing is that if you're going to have a lot of tests, then it's a good idea to pad the numbers.  instead of 1, 2, 3 try 10, 20, 30.<br>
<br>I went a bit overboard here ...<br><br>010-useability.t  023-compfile.t    031-uncompfile.t      040-memory.t         070-gzcomp.t<br>
011-prototype.t   024-compfile.t    032-uncompfile.t      041-error.t          071-gzuncomp.t<br>020-compfile.t    025-compfile.t    033-uncompfile.t      050-deflate.t        080-version.t<br>021-compfile.t    026-compfile.t    034-uncompfile.t      051-deflate-flush.t  081-basic.t<br>

022-compfile.t    030-uncompfile.t  035-uncompreadline.t  060-inflate.t        082-stream.t<div class="HOEnZb"><div class="h5"><br><br><br><br><div class="gmail_quote">On Sat, Mar 3, 2012 at 10:13 AM, Rob Janes <span dir="ltr"><<a href="mailto:janes.rob@gmail.com" target="_blank">janes.rob@gmail.com</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">i always do a useability test.  this is one of those cases where ok() does not do the trick.<br><br>from Test::More man page:<br>

     You usually want to test if the module you're testing loads ok, rather than just vomiting if its load fails.<br>
     For such purposes we have "use_ok" and "require_ok".<br><br>Note the modeline for emacs and vim.  test files normally end with .t, and neither vim nor emacs automatically detect them as perl.<br>

<br>
modelines can usually go in the first 5 or last 5 lines.<br><br># -*- mode: perl -*-<br># vim: set expandtab autoindent nows sts=2 sw=2:<br><br>use Test::More tests => 2;<br><br>## this tests the useability of the package<br>


<br>BEGIN {<br>  use_ok('Compress::Bzip2');<br>};<br><br>my $version = $Compress::Bzip2::VERSION;<br>ok( $version, "Compress::Bzip2 version is $version" );<div><div><br><br><br>
<div class="gmail_quote">On Fri, Mar 2, 2012 at 8:29 PM, James E Keenan <span dir="ltr"><<a href="mailto:jkeen@verizon.net" target="_blank">jkeen@verizon.net</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">So it turns out that the folks organizing the DC-Baltimore Perl Workshop () want their tutorial-type presentations to run in 50-minutes timeslots -- not 20.  Which means I can actually add considerable material to the "82% of what you need" talk I gave last week.<br>



<br>
What else should I cover in a talk for those new to Perl testing?  I welcome your suggestions.<br>
<br>
(Below:  My own brainstorming.)<br>
<br>
* Introduce ok() at an even more basic level: use of Test::Simple::ok() in a program (as distinct from testing functions from a package).<br>
<br>
* Definitionally-oriented introductions of Test::Builder and Test::Harness.<br>
<br>
* Mention of other prominent Test::* classes (though I actually don't use them much because I already accomplish so much with Test::More).<br>
<br>
* Introduction of concept of coverage analysis.<br>
<br>
* Introduction of concept of test-driven development.<br>
<br>
* Illustration of use of 'make test' and './Build test'.<br>
<br>
Your thoughts?<br>
<br>
jimk<br>
______________________________<u></u>_________________<br>
toronto-pm mailing list<br>
<a href="mailto:toronto-pm@pm.org" target="_blank">toronto-pm@pm.org</a><br>
<a href="http://mail.pm.org/mailman/listinfo/toronto-pm" target="_blank">http://mail.pm.org/mailman/<u></u>listinfo/toronto-pm</a><br>
</blockquote></div><br>
</div></div></blockquote></div><br>
</div></div></blockquote></div><br>