[tpm] Follow-up on Feb 2012 Testing Talk

[Rob Janes]

one last thing ... maybe ...

other test frameworks like perl test:

gtest http://code.google.com/p/googletest/ for c++

If anybody has tried cppunit or junit, what I like about perl test is how
succinct and readable the test output is.  As opposed to junit or cppunit
where the test output is absolute crap.

gtest output is much like perl test.  but perl was first.



On Sat, Mar 3, 2012 at 10:38 AM, Rob Janes <janes.rob at gmail.com> wrote:

>
> Another thing I'd suggest is to NOT use the last argument of ok() as a
> label.
>
> The message argument of all those test functions is only displayed if
> there's something wrong, if the test fails.
>
> It's most useful if the message tells you what failed.  For example,
> instead of
>
> ok( open(my $fh, "> logfile"), "open logfile succeeded");
>
> this would make more sense, since the message only shows if the test fails:
>
> ok( open(my $fh, "> logfile"), "open logfile failed: $!" );  # open should
> succeed
>
> 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.
>
> The expectation is open should succeed.  If it fails, the message is
> displayed with the error reason.
>
>
> On Sat, Mar 3, 2012 at 10:18 AM, Rob Janes <janes.rob at gmail.com> wrote:
>
>> 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.
>>
>> I went a bit overboard here ...
>>
>> 010-useability.t  023-compfile.t    031-uncompfile.t
>> 040-memory.t         070-gzcomp.t
>> 011-prototype.t   024-compfile.t    032-uncompfile.t
>> 041-error.t          071-gzuncomp.t
>> 020-compfile.t    025-compfile.t    033-uncompfile.t
>> 050-deflate.t        080-version.t
>> 021-compfile.t    026-compfile.t    034-uncompfile.t
>> 051-deflate-flush.t  081-basic.t
>> 022-compfile.t    030-uncompfile.t  035-uncompreadline.t
>> 060-inflate.t        082-stream.t
>>
>>
>>
>>
>> On Sat, Mar 3, 2012 at 10:13 AM, Rob Janes <janes.rob at gmail.com> wrote:
>>
>>> i always do a useability test.  this is one of those cases where ok()
>>> does not do the trick.
>>>
>>> from Test::More man page:
>>>      You usually want to test if the module you're testing loads ok,
>>> rather than just vomiting if its load fails.
>>>      For such purposes we have "use_ok" and "require_ok".
>>>
>>> Note the modeline for emacs and vim.  test files normally end with .t,
>>> and neither vim nor emacs automatically detect them as perl.
>>>
>>> modelines can usually go in the first 5 or last 5 lines.
>>>
>>> # -*- mode: perl -*-
>>> # vim: set expandtab autoindent nows sts=2 sw=2:
>>>
>>> use Test::More tests => 2;
>>>
>>> ## this tests the useability of the package
>>>
>>> BEGIN {
>>>   use_ok('Compress::Bzip2');
>>> };
>>>
>>> my $version = $Compress::Bzip2::VERSION;
>>> ok( $version, "Compress::Bzip2 version is $version" );
>>>
>>>
>>>
>>> On Fri, Mar 2, 2012 at 8:29 PM, James E Keenan <jkeen at verizon.net>wrote:
>>>
>>>> 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.
>>>>
>>>> What else should I cover in a talk for those new to Perl testing?  I
>>>> welcome your suggestions.
>>>>
>>>> (Below:  My own brainstorming.)
>>>>
>>>> * Introduce ok() at an even more basic level: use of Test::Simple::ok()
>>>> in a program (as distinct from testing functions from a package).
>>>>
>>>> * Definitionally-oriented introductions of Test::Builder and
>>>> Test::Harness.
>>>>
>>>> * Mention of other prominent Test::* classes (though I actually don't
>>>> use them much because I already accomplish so much with Test::More).
>>>>
>>>> * Introduction of concept of coverage analysis.
>>>>
>>>> * Introduction of concept of test-driven development.
>>>>
>>>> * Illustration of use of 'make test' and './Build test'.
>>>>
>>>> Your thoughts?
>>>>
>>>> jimk
>>>> ______________________________**_________________
>>>> toronto-pm mailing list
>>>> toronto-pm at pm.org
>>>> http://mail.pm.org/mailman/**listinfo/toronto-pm<http://mail.pm.org/mailman/listinfo/toronto-pm>
>>>>
>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.pm.org/pipermail/toronto-pm/attachments/20120303/8acc861f/attachment.html>