Some of you may remember me talking quite a bit about Veure a few years ago when I was living in Amsterdam. I never discussed on the Web what it was about.

Now it's time to fess up, but I've posted the story of Veure to my personal blog instead of blogs.perl.org because it's not really about Perl (and blogs.perl.org kinda struggles with images). Veure was/is a Perl-based MMORPG. It's not done, but I included a few screenshots.

I'm back from the Perl QA Hackathon and had a blast. I really appreciated the work that BooK and Laurent did to pull this off. And thanks to Booking.com for hosting us. In fact, we had a wide variety of sponsors and I suggest you check them out if you're looking for a new position.

To summarize what I did:

• I released TAP::Stream to let people merge multiple streams of TAP.

Very useful if you distribute tests across multiple boxes or want tests running in multiple processes.

• I released a new version of Test::Class::Moose.

This version makes it easier to migrate from Test::Class.

• I posted a clean, annotated dist.ini.

It's a good starting point for those (like me) who are new to Dist::Zilla.

• I then released yet another version of Test::Class::Moose.

This version makes method attributes required. There's simply too much benefit for them in tests and making them optional complicated the code too much.

• I uploaded a new version of DBIx::Class::EasyFixture.

This allows you to disable transactions, if you need to.

• I started writing The Zen of Test Suites.

This document explains my (not so humble) opinions about what is needed to write tests for applications.

All things considered, I think this was a very successful hackathon for me. I even have a lead for a rather interesting contract.

Today's the last day of the Hackathon and it's gotten off to an interesting start: we were locked out of the Booking.com offices (it appears to be accidental), so now we're overflowing the hotel lobby. The organizers have gotten us a small room in the hotel and now we're slowly moving there.

Yesterday I fixed a few issues with Test::Class::Moose and also uploaded a new version of DBIx::Class::EasyFixture, one which allows developers to disable the transactions, if they prefer.

In other news: Test::Class::Moose is NOT for testing Moose-based code: it's for testing. If you code uses Moose, great. If not, great. The name "Moose" is in there simply because it's Moose-based. I realize, in retrospect, that this was a mistake: I shouldn't have coupled the name with the implementation. That being said, there are worse things I could have called it.

Also, no, there will probably not be a Test::Class::Moo (at least, not written by me). This isn't because I object to Moo, but because Test::Class::Moose uses meta-programming internally, including method modifiers to add plans for those who use the Test and Tests attributes. Much of my use of meta-programming could be done with Moo and walking symbol tables, or using Class::Inspector, so if you want to take a crack at it, go ahead!

Today, aside from giving an interview which will be published in Norway, I released yet another version of Test::Class::Moose. As of version 0.51, the Sub::Attribute module is required rather than optional. Thus, all the nifty attribute goodness, such as Test, Tests, and Tags should just work, rather than requiring another module to install after your code breaks.

This is day 3 of the Perl-QA Hackathon in Lyon, France, and I decided it was time to fix some issues with the older dist.ini I was using. Erik Colson asked about my dist.ini, so I thought I should explain it here, along with comments.

I've just released Test::Class::Moose version 0.50. The major feature you'll notice are the Test and Tests attributes. They're included to make it easier to migrate from Test::Class.

sub this_is_a_test : Test {
    pass 'we have a single test';
}

sub another_test_method : Tests { # like "no_plan"
    # a bunch of tests
}

sub yet_another_test_method : Tests(7) { # sets plan to 7 tests
    ...
}

And for those already familiar with TCM, you'll note that if you use a Test/Tests attribute, it's automatically a test method and the method name no longer needs to be prefixed with test_.

There are also some minor tweaks that I made to parallel testing (internals cleanup, mostly).

For those wondering why you would use Test::Class::Moose: if someone builds a web site out of hundreds of separate scripts with embedded SQL and printing output directly, we call it legacy crap ... but we're perfectly OK with that in a test suite.

Treat your test code as well as your regular code. Don't just slap something together and hope it works.

Update: Thinking about simply declaring Sub::Attribute as a dependency rather than making it optional. It would simplify the code internally, but the magic of Sub::Attribute could conceivably break at some point? Thoughts?

If you're interested in hiring me or any of the talented developers we have working at All Around The World, drop me a line at ovid@allaroundtheworld.fr.

I'm at the Perl QA Hackathon in Lyon and it's been an interesting trip so far. I missed my flight yesterday, so I had to fly out this morning — only to get to the airport and discover that I left my passport at home. Fortunately, the hackathon is in Lyon, France, so I was able to use my Titre de Sejour (residence permit) instead. Then the coffee machine ate my money.

Then shortly after I get to the hackathon (after four hours of sleep followed by four hours of travel), Leon Timmermans hit me with an interesting problem regarding parallel tests in Test::Harness. I came up with an approach that isn't as sexy as his, but is far simpler and it involves a module I released today, TAP::Stream.

The upcoming subroutine signatures in Perl aren't needed so that Perl can be "cool" (we're long past that). They're needed to make your code more correct.

I have a client that I sometimes write code for and they have the layers of their application nicely defined. Their front-end code makes AJAX calls back to an API written in Perl. That, in turn, calls their backend code, also written in Perl. Much of their API code resembles this:

sub get_something { 
    my $self = shift; 
    my ( $id, $foo, $bar ) = validated_list( 
        \@_, 
        id  => { isa => 'Int' }, 
        foo => { isa => 'Int|Undef' }, 
        bar => { isa => 'Str|Undef' }, 
    ); 
    ...
}

I'd much prefer to write:

method get_something(Int $id, Int|Undef $foo, Str|Undef $bar ) {
    ....
}

But I generally can't, so I settle for what I can get.

This client's backend code often relies on their API code calling them with the correct parameters. What they've done is adopt a strategy of putting their validation/sanitation in their API. What happens if they miss some validation in their API? Fortunately, they have decent tests, but in reality, many developers test against the data they expect to receive, not the unexpected data.

So why don't they have tighter validation on their backend? Much of that relies on database calls using bind parameters and not interpolated SQL, so it seems relatively safe compared to most systems, but they don't too as much validation on the backend because it's so time-consuming to write and it can impact performance. They're relying on their clean API to handle this for them.

This is one area in which Perl is very embarrassing.