einhverfr has asked for the wisdom of the Perl Monks concerning the following question:

Esteemed monks,

I have some integration tests I am trying to write for an AnyEvent test loop which uses Coro to avoid deadlocks when I send data to Etcd using Net::Etcd. This means that the tests which introspect the event happen inside a Coro unblock_sub call.

Everything mostly works except for the fact that I don't always get all the test output.

My working theory is that the initial events run and schedule coros which get run after. These then run, in order etc. But I suspect that somewhere along the line the output is truncated.

Has anyone here seen a similar problem testing AnyEvent/Coro apps?
  • Comment on Seemingly Truncated Test Output with Coro, AnyEvent and Test2::V0

Replies are listed 'Best First'.
Re: Seemingly Truncated Test Output with Coro, AnyEvent and Test2::V0
by GrandFather (Saint) on Nov 13, 2023 at 04:42 UTC

    No, I've never seen that issue.

    Perhaps if you showed us some sample test code that reproduces the problem we might be able to help more?

    Optimising for fewest key strokes only makes sense transmitting to Pluto or beyond

      So my working model has changed. I will need to do some more research and report back.

      When I count the tests that should run manually, I get 38 tests. However, the script seems to only run between 28 and 36 tests. What's particularly strange here is that I can call done_testing() and it works if I do it before I shut down an external etcd daemon used in the testing. I had previously thought the error was truncated output because done_testing didn't seem to work but this is more of an output order issue.

      Running the test manually confirms a variable number of tests actually run before I come to an end-of-test condition. I now think the problem is coros being scheduled but not run yet But they seem to always run in the desired order, so I am confused here.

        Not what you asked about, but possibly related to your scenario, if you are starting a background daemon using an object and expecting the object destructor to shut down the daemon when the object goes out of scope, you need to make sure to undef the object before the end of the script. At the end of the script Perl enters "global destruction" and just starts running destructors in any old order, which then tend to fail because they wanted to look at data that already got garbage collected.

        I'll let you confirm or deny this possibility before I speculate further.