Extensive POE Testing PT. 5 - Testing, Seq-Ordered and Count

# drawing from a previous example:
package Session;
use MooseX::POE;
use Test::More;
with 'POE::Test::Helpers'; # actual title

has '+seq_ordering' => ( default => sub { {
    START => 1,
    next  => 4,
    more  => 4,
    last  => { 1 => [ 'START', 'next', 'more' ] },
    STOP  => [ 'START', 'next', 'more', 'last' ],
} } );

my $count = 0;
sub START           { $_[KERNEL]->yield('next') }
event 'next' => sub { $_[KERNEL]->yield('more') };
event 'more' => sub {
    $count++ < 3 ? $_[KERNEL]->yield('next') :
                   $_[KERNEL]->yield('last');
};
event 'last' => sub { 1 };

# adding the runner
package main;
use Test::More tests => 6;
use POE::Kernel;

Session->new();
POE::Kernel->run();

Here we can see how our test requirements are declared:

• START runs only once
• next runs four times
• more runs four times
• last runs once
• last runs ONLY after START, next and more
• STOP runs only after all the other events

That comes out to 6 tests. That's what we wrote in the Test::More plan and this is the result:

$ perl -Ilib t/articles/2.t 
1..6
ok 1 - Correct sequence for last
ok 2 - Correct sequence for STOP
ok 3 - (next) Correct number of runs
ok 4 - (START) Correct number of runs
ok 5 - (last) Correct number of runs
ok 6 - (more) Correct number of runs

We can see that it only tested last and STOP for sequence ordering (or event dependency). Also, it only checked the number of correct runs on next, START, last and more.

You might notice the test output didn't come out in the same order the events ran. That's because it takes them from the attribute we set, which is a hash and hence, has no order.

What next?
While I'm working on releasing it today to Github and hopefully soon enough to CPAN as well, I still have a few things to go over. There's one more type of tests that I found the most important for me and it's pretty sweet. I intend to write another post or two on that. Then I'm going to present the framework (it should already be on CPAN by that time) and show a pretty insane race condition we found at $work and tested using this framework. Stay tuned!