On Wed, Jul 8, 2015 at 9:02 AM, Alceu R. de Freitas Jr. <
glasswal...@yahoo.com.br> wrote:

> Did you had such situations in the past and could share your experience
> with it? I'm not sure the best approach to avoid those failures. Maybe
> executing the tests under eval, inside a while loop and sleeping for a
> random number of seconds?
>

I really didn't understand your description of what's happening in your
code, but here are some general ideas I try to follow:

* Test can be run in parallel (see the -j flag to prove) so you should
never assume that different *.t files won't collide.  If you keep that in
mind, then a smoker running your module under two or more different perls
at the same time will also not cause problems.

* Never use the same "temporary" path for testing in different *.t files,
either under /tmp or under the current directly.  Always create a unique
temporary directory if you need to write files and write everything under
that.  I wrote Test::TempDir::Tiny as a reasonably good way to do that
safely even under concurrent operations.

* Never hard code a port number for server operations.  Use Net::EmptyPort
instead.  For testing client/server operations, consider Test::TCP if it
can fit your needs.

* If a test file needs to start up some daemon in the background (perhaps
listening on an empty port), it must also shut it down.  Consider
Proc::Guard for that.

* Never grep the process table expecting only to find one of something.

* If you really must control which tests are allowed to run in parallel,
require Test::Harness 3.31 or later (or skip the test) and use a rules
file.  (Read TAP::Harness docs about rules and see
https://github.com/mongodb/mongo-perl-driver/blob/master/t/testrules.yml
and https://github.com/mongodb/mongo-perl-driver/blob/master/t/max_time_ms.t
for examples.)

Hope that helps,
David

-- 
David Golden <x...@xdg.me> Twitter/IRC: @xdg

Reply via email to