mjemmeson.myopenid.com

• Website: mjemmeson.myopenid.com/
• About: I blog about Perl.

Recent Actions

• Commented on How to write a test description
  On the subject of better test descriptions, 'note' is very useful for separating out blocks of tests when reading test output....
• Commented on How to surf the website with help of Perl
  You don't say what you've done already (to open the website). You probably want to look at something like WWW::Mechanize if you haven't already. Also try asking over at http://stackoverflow.com instead - that is a question and answer site specifically...
• Commented on Unicode rant
  it looks like the inverse of the 5.14 'use unicode_strings' feature would be useful in these cases (i.e. get Perl to never auto-promote strings). I wonder if one has been proposed? (using 'no feature unicode_strings' wouldn't work because that would...
• Commented on XML::Tiny bugfix - and last post here for a while
  the apparent lack of previous/next/older/newer links anywhere on the site is nice too...

Comment Threads

• Vyacheslav Matyukhin commented on Unicode rant

  Oh, I see, it's because byte-strings are also latin-1 strings. I should read 'perlunicode' before getting into arguments...

• Mark Stosberg commented on How to write a test description

  Here's one case I've found where no test description is better than having one.

  With Test::WWW::Mechanize, get_ok() has a default test message that prints the URL that is being fetched.

  These can often be constructed using query strings which were dynamically generated by the test.

  Often times, descriptions for these tests ending being something like "get the page".

  Here's an example:

  not ok 1 - Get a page

  Failed test 'Get a page' at /home/mark/tmp/t.pl line 9. 404 Not Found

  1..1

  If the test fails and I need to de…

• doomvox.myopenid.com commented on How to write a test description

  Yup... Further, I would add that an optimistic description that implies success makes the test output hard to read:

  not ok 2 - things are working perfectly

  It's easy to miss the "not" when there's a long chunk of text telling you everything is fine.

  I use the somewhat verbose practice of beginning every test description with a phrase like "Testing that...". That forces me to write a description that makes sense if the test fails or succeeds.

• Olivier Mengué (dolmen) commented on How to write a test description

  Don't complain: your project at least has test descriptions!

  I'm dreaming of a Perl::Critic policy (or a super test) that would make test descriptions mandatory.

• adamlounds commented on How to write a test description

  Loving this test style.

  We're trying to follow a strict two-line format in the perl code, which makes the tests really easy to skim through.

  ok my $thing = Classname->new( %args ),
    "Can create a Classname";
  
  is $thing->accessor, $expected_value,
    "... and attribute was set ok";
  
  ok my $result = $thing->method_call,
    "... and can method_call";
  
  is $result, $expected_value,
    "... and method_call returned thing_we_wanted";
  

  /me is enjoying not creating tmpvars on their own lines all the time and having oodles of space to write test descriptions :-)