Slash Boxes
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)

  (email not shown publicly)

Journal of xsawyerx (8978)

Thursday October 01, 2009
06:28 AM

Testing MooseX::POE code

[ #39702 ]

Currently I maintain a pretty complex app that makes a heavy use of POE sessions. The sessions go on and off, and phase out while the app is starting a new stage in which other sessions are created and maintained.

POE has definitely been comfortable to work with in the manner of handling the sessions. We also use Moose in the code to maintain the heavy attribute usage we have. It was natural to use MooseX::POE to easily create sessions that have Moose attributes.

The problem I ran into was trying to write tests for it. I picked a certain part of the code, a session class, and tried to write a test for it. I tried using various methods such as Sub::Override, subclassing the subroutines, using "before" and "after" (Moose goodness) and failed horribly in all.

I think the main problem was that I couldn't subclass the START event and other events defined using MooseX::POE syntactic sugar. It was very frustrating trying to weed through all of it.

I think the biggest realization that hit me through the process was that POE is one of the most elaborate frameworks I know (esp. in the event-based programming world) but it lacks a formal testing mechanism. Be it proper documentation, base test modules or even placeholder test examples, some mechanism should exist.

I'm reading up on how others do tests and it's beyond inconsistent. Often times they test the wrong part of have no real way of testing every little bit. Sure, I can set up a server, run the app and then see if the server was configured correctly, but that would be missing the entire point of tests. I want to see that a certain event was run. I want to validate the parameters. I want to see if a certain event wasn't run at all. Etc. etc.

I've literally abandoned the tests and instead opted for a dry run mode (which doesn't change anything in the DB) and a debug output by levels (to really see what the code is doing). I guess I would have better success at the subclassing idea if I'd be using POE::Session but I'd hate to bloat the code or make it as ugly as I think it is with POE::Session. with MooseX::POE it's clean and beautiful. I want to keep it that way.

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
More | Login | Reply
Loading... please wait.
  • I've had some minor success writing test scripts for POE::Declare components, perhaps I should write up some journal stuff on how I did it.

  • Yesterday I was finally able to make some progress.

    In my project, one of the packages loads a set of extensions coming from an inner namespace. If I abstract it enough (to make it load the extensions of a given namespace - using an attribute), I can subclass the package, create a package that it will load as an extension, I can then make sure it loads it correctly.

    However, I can only test it by the subclassing an event, since it loads a Role. So, I have to abstract it some more.

    I don't know if it's a "god d