Of course I still use Perl

I'm trying to standardize on test labels that use affirmative language to say what should have happened if everything went correctly, like "Connected to database using valid username and password" or "Failed to connect to database using invalid username".

The short identifiers might make sense to you, but they won't make sense to anyone else who starts working on your project.

The longer one. Definitely.

Definitely the longer names are better. Even though tests aren't really documentation in the sense that many people think of them, they can serve that role if well-handled. For example, I have a test method in my current project which just checks to ensure that a normal user cannot access the "admin" page and that they'll be sent back to the login screen. Here's what you see if you run that test method:

    1..3
    ok 1 - Normal users can try to get to the admin page
    ok 2 - ... and they should be told that they need admin privileges
    ok 3 - ... and they should be sent back to the login page

This narrative style of test names gets us a lot closer to tests as documentation. The test names describe the behavior in a way that the actual code does not. So if I had omitted the test names, here's what the code would have looked like:

    sub not_admin : Tests(3) {
        my $test = shift;
        my $mech = $test->test_mech;
        $mech->user_login;
        $mech->get_ok('/admin/');
        like $mech->content, qr/You need to be an administrator to view this page/;
        is $mech->uri->path, '/login';    
    }

In other words, you can kind of get a sense of what's going on, but the descriptive test names allow anyone to return to this months later and instantly know what's going on and why, rather than trying to parse code.

Hmm, this should be a top-level blog entry. Thanks for the idea :)