I'm putting this here in case anyone else sees this or hits a search engine looking for the problem.

This morning I had to restart my iMac thanks to the lovely security hole Apple patched and my default perlbrew was set to version 5.18.1, though I was developing in 5.18.2. I ran a test and immediately had the following mysterious error:

Invalid version format (version required) at ... /5.18.1/Module/Runtime.pm line 386.

The fix is both simple and complicated.

I recently posted about DBIx::Class::EasyFixture and I was shocked to receive an email from someone explaining how he uses it in production with Test::Class::Moose. Basically, the ability to write this was the killer feature for him:

sub test_teardown {
    my $test = shift;
    $test->fixtures->unload;
}

First of all, thank you to everyone who has joined gittip. So far we've put Perl into the top ten largest communities on the site and even passed the Ruby on Rails community. Keep it going!

Next, I've decided to upload a very strange module to the CPAN, one that may prove incomprehensible to most folks, but if it works, it might make working with DBIx::Class a bit more interesting (for curious values of 'interesting'). In short, it allows you to automatically create an object hierarchy of objects that delegate off to their DBIx::Class counterparts rather than inherit from DBIx::Class. That sounds weird, but let me explain.

By now you may have heard of gittip and wondering "why should I bother?"

Gittip is a way of donating small amounts of money to people who inspire you. That's an important point here. Peter Rabbitson, the maintainer of DBIx::Class, made a strong plea for people helping one another on gittip, but I'm going to make a slightly different argument for joining gittip, one that won't cost you a penny.

No, not Perl, but open source developers in general. It seems that FusionCharts is openly mocking open source developers on their front page, but use open source extensively.

As part of my rewriting of my testing classes (tired of hearing about it yet?), I found myself at the part where I needed to explain test fixtures. A fixture, in this context, is simply a particular known state that you can test against. In particular, I'm focusing on using database fixtures in tests. There's not a lot of good discussion about this and that's unfortunate because fixtures can really benefit your test suite.

If you avoid DBIx::Class because of performance issues, you should probably check out version 0.08250 or better. In an interesting note from the Changes file:

Rewrite from scratch the result constructor codepath - many bugfixes and performance improvements (the current codebase is now capable of outperforming both DBIx::DataModel and Rose::DB::Object on some workloads).

Previously I used it because with DBIx::Class::Schema::Loader, I could pregenerate my classes from a database schema and it's fairly robust. When the database changes, I can regenerate my classes on the fly and and run the tests to verify that nothing's broken. However, I hit upon a case where it generated some bad code. As it turns out, DBIx::Class::Schema::Loader was correct and it revealed a bug in my database design.

As an experiment, our company, All Around The World has released some of our Perl testing training material for free. You can read more about this and our motivations at our blog.