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

use Perl Log In

Log In

[ Create a new account ]

xsawyerx (8978)

xsawyerx
  (email not shown publicly)

Journal of xsawyerx (8978)

Friday October 09, 2009
09:32 AM

Extensive POE Testing PT. 2 - Testing, Ordered

[ #39734 ]
A special thanks goes here to Adam Kennedy for sending me on this path and giving me ideas. Adam, I wanted to thank you personally but couldn't catch you on IRC, so thanks! :)

I tried to cover in my last post the basic guidelines I have for testing in POE. Testing in POE is different since we want to test a flow and not just subroutines. This time I want to try go over the first type of tests that I find necessary. It's called ordered tests - at least that's how I call it.

This method was first hinted at me by the great Adam Kennedy who used it in his POE::Declare module. Basically it describes the following scenario: I have a POE::Session event flow and I want to make sure that every event is run at the specific order.

package MyPackage;
use MooseX::POE;
use Test::More;

# this is taken from POE::Declare's t/04-stop.t
my $order = 0;
sub order {
    my $position = shift;
    my $message  = shift;
    is( $order++, $position, "$message ($position)" );
}

# then we can do this (written in MX::POE)
event 'eg' => sub {
    order( 0, 'Started eg event' );
};

Now, each event could run this subroutine with a number indicating the order of this event in our overall flow of the session. Here, for example, with the order( 0, 'event name' ) code if any event is running at a time that wasn't meant for it, it will fail.

However, it has a few disadvantages:

  • If any of the events repeat, it creates a problem. You'll have to set up a system to check which iteration of the event it is and execute the correct order()
  • What if you're yelding the kernel for two events and you aren't sure which one will run first?
  • What if it doesn't matter which one will run first?
  • What about running two sessions of the same object? It has the exact same events, with the exact same code. It will fail for sure.

My suggestion: allow a test that checks for event dependency. Instead of saying "this runs first", you could say "this runs ONLY after that" and "this - this runs only after these two". That would allow to have an order based on a sequence of events. Each event can only come after different events.

This is what the next post will discuss.

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • The reason I prefer my syntax to your dependency based on is that mine is easier to write and maintain, or so I find.

    Of course, I completely acknowledge that it is intended for simple situations where the order is easily knowable.

    • Actually, my framework supports this specific type of tests and it looks very similar to the way you do it:

      use MooseX::POE;
      with 'POE::Test::Simple'; # again, working title
      event 'next' => sub {
          $_[OBJECT]->order( 2, 'Running next' );
      };

      Only difference is mine is a Moose role that adds the order as a method of the session object. I started by implementing your method as a role and then noticed I need more options so I added more bells and whistles (which I'm now writing about).

      However, I'm