Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

Display Options Threshold:
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
  • Note: it's been agreed at work that reproducing BBC code here is acceptable as the public pays for this code and we really don't have "business secrets" in the sense that other businesses do.

    I understand what you're saying, but there's a critical difference here. Test names are embedded in the tests and tend not to get misplaced. They're also close enough to their code that they're easier to keep in synch.

    Many times I find that the tests are opaque to the point of incomprehensibility and I'm forced to read comments or the test names to get some sense of what the tests are doing. For example, one of our tests at work has the following code:

    my $xml = slurp( $tva_file );

    ok !import_xml( $schema, $xml, 1 ), 'imported xml';

    my $change_rs = $schema->resultset('ChangeEvent');

    is $change_rs->count, 12, 'found 12 change events';

    my $failed_change_event_count = $change_rs->search({
        status  =>  'failure',
    })->count;

    is $failed_change_event_count, 12, '12 failed change events';

    Why do we have "12 failed change events"? Who knows? The code doesn't say and the test names can be deleted without loss of clarity. And the test file name itself? "episode_pid_shenanigans". Excuse me? Try this:

    my $xml = slurp( $tva_file );

    ok !import_xml( $schema, $xml, 1 ), 'Importing broadcasts without episodes should fail';

    my $change_rs = $schema->resultset('ChangeEvent');

    is $change_rs->count, 12, '... but there should be a change event for each broadcast';

    my $failed_change_event_count = $change_rs->search({
        status  =>  'failure',
    })->count;

    is $failed_change_event_count, 12, '... and they should be failed change events';

    Now the test names are clear, self-documenting and not reliant on comments being misplaced in the code. Perfect, no. Better? Hell yes! :)

    We have other tests which verify that broadcasts can have duplicate start times. Why on earth should they be allowed to have duplicate start times? The test says nothing about this. So I thought "hey, many they're on different channels?", but when I dug through their fixtures, they were on the same channel. Eventually I had to drag our acceptance tester over and he guessed that subsequent broadcasts overwrite previous broadcasts. Turns out that this is true, but there was nothing in the tests which made it clear. Perhaps these are bad tests, but if the output of the were written in a narrative style explaining the intent, this might have been easier to track down.