For my current contract I'm doing a huge amount of testing on a system that is very fun to hack on. I've also been given a lot of rope leeway in how I test. Thus, I use Test::Most quite heavily, but I've a tiny problem:

use Test::Most 'die';

That should halt the test file at first failure, a feature I use quite a bit when developing to ensure that test failures don't scroll past when I'm actively hacking on code. However, when I added subtests to Test::Builder a few years ago, I made sure that a fatal failure in a subtest would cause the subtest to fail, but not the entire test program. Well, darn. That means use Test::Most 'die' doesn't quite do what I want it to do in this case.

Being pragmatic, I did the simplest thing which can possibly work. I used the testing equivalent of weapons of mass destruction:

use Test::Most 'bail';

Thus, any test failure will cause the test suite to bail out, immediately, no questions asked! I don't mind this behavior at all when I'm hacking on a single test program, but I don't want to commit that, so I must remember to remove that before I commit.

Well, of course I committed that; the more manual steps you make anyone take, the more likely they are to forget one. Time to make sure I don't do that again.

I've been having a great time at YAPC::NA (my first YAPC In the US) and so far everything's been going swimmingly ... well, except for when I was giving a lightning talk and my phone kept buzzing in my pocket because my wife was lost.

I gave a talk on Test::Class::Moose and there were plenty of interesting questions and many of them were about topics I would like to have included in the talk, but simply didn't have time. One person emailed me later asking me a detailed question about test control methods and while I've discussed this before, I thought it was important to re-explain a common anti-pattern I see in Test::Class test suites.