in reply to How to write time-related test without race conditions?

Why are you using EV, why not sleep, or select?

  • Comment on Re: How to write time-related test without race conditions?

Replies are listed 'Best First'.
Re^2: How to write time-related test without race conditions?
by powerman (Friar) on May 14, 2012 at 19:56 UTC
    Because this module designed to be used in event-based applications.

      Hmm, so is EV::timer blocking like sleep/select? Does it enforce order of timers?

      Maybe you can check if timer went into overtime (M) and do Test::More::skip() instead of is(), or simply rewrite your is() check to notice overtime?

        Using skip() is probably possible, but this mean test won't do it's work, partially or completely. This isn't differ too much from just removing this test. And this will make test unreliable - it may pass even if there is a bug in module, and on next run it may fail and catch this bug. Actually I prefer current behavior - when test may fail because of high system load, but if it pass - that mean module work correctly… for me it's much better than opposite behavior with skip(), when test may pass when there is a bug in module.

        As for adding check to analyse overtime, this way lead to implementing very overcomplicated test - it should generate some events at unpredictable points of time to access cache, then it should run some amount of checks, also at unpredictable points of time, and these checks should first calculate expected state of cache at current time and then compare this state to actual state of cache. In addition to be overcomplicated, such test also can't guarantee it will correctly test all functionality of cache - for example, attempt to test item in cache won't expire before expected time will fail if function which checking this will always run too late (after item will be expired from cache). So, we again get unreliable test, plus overcomplicated.