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<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">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 class="HOEnZb"><div class="h5"><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>