Testing event-based programs is not trivial at all. There's a lot of hidden race conditions and unknown behavior afoot. Usually we separate the testing to components, subroutines and events. However, as good as it is (and it's good!), it doesn't give us the exact behavior we'll get from the application once running.

There are also a lot of types of tests that we would want to run, such as:

Ordered Events:

Did every event run in the specific order I wanted it to?

(maybe some event was called first instead of third...)

Sequence Ordered Events:

Did every event run only after other events?

Imagine you want to check whether run_updates ran, but you know it can should only run after get_main_status ran. In event-based programming, you would give up the idea of testing this possible race condition, but with Test::POE::Helpers you can test it.

A callback to create your session. This is required so POE::Test::Helpers could hook up to your code internally without you having to set up hooks for it.

The callback is expected to return the session object. This means that you can either provide a code reference to your POE::Session->create() call or you could set up an arbitrary code reference that just returns a session object you want to monitor.

Describes what tests should be done. You need to provide each event that will be tested and what is tested with it and how. There are a lot of different tests that are available for you.

You can provide multiple tests per event, as much as you want.

POE::Test::Helpers->spawn(
run => $run_method,
tests => {
# testing that "next" was run once
next => { count => 1 },
# testing that "more" wasn't run at all
more => { count => 0 },
# testing that "again" was run 3 times
# and that "next" was run beforehand
again => {
count => 3,
deps => ['next'],
},
# testing that "last" was run 4th
# and what were the subroutine parameters each time
last => {
order => 3, # 0 is first, 1 is second...
params => [ [ 'first', 'params' ], ['second'] ],
},
},
);
POE::Kernel->run;