Re^4: How to write time-related test without race conditions?

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.

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

Replies are listed 'Best First'.
Re^5: How to write time-related test without race conditions? by Anonymous Monk on May 15, 2012 at 00:00 UTC
This is not quantum-mechanics. Tests are supposed to be predictable, and the expectations are supposed to be predictable. Tests are supposed to verify your expectations (assumptions). If you're in overtime, if the cache has expired, then the test expectation must change from ->get('test') returns 1 to ->get('test') returns nothing Failing the test because you're in overtime is a poorly written test. EV should make it simple to detect overtime, if it doesn't, you can detect overtime with minimum of code additions to your 30 line test. But I now see the real problem, you're using EV to implement expiration, but that is something every caching module ( Cache/CHI .. ) knows how to do without an event loop; in short, the module has no use case	[reply]
Re^6: How to write time-related test without race conditions? by powerman (Friar) on May 15, 2012 at 01:41 UTC
If you're in overtime, if the cache has expired, then the test expectation must change from ->get('test') returns 1 to ->get('test') returns nothing As I already said, this will make test to pass, but same effect will be from `ok(1)` because this test won't test things it's supposed to test in this case. Failing the test because you're in overtime is a poorly written test. Agreed, this is why I've posted this question. But I now see the real problem, you're using EV to implement expiration, but that is something every caching module ( Cache/CHI .. ) knows how to do without an event loop; in short, the module has no use case Modules which implement this without EV have to either lose noticeable amount of performance for cache housekeeping on each `$cache->get()` and `$cache->set()`, or require user to don't forget to manually call `$cache->housekeeping()` every few seconds (which usually mean adding this operation into many different places of code to guarantee it will be called often enough). In event-based applications we can avoid both performance loss and chaos in code by simply using EV->timer to call housekeeping code internally in module. This is the use case for this module.	[reply] [d/l] [select]
Re^7: How to write time-related test without race conditions? by Anonymous Monk on May 15, 2012 at 03:07 UTC
As I already said, this will make test to pass, but same effect will be from ok(1) because this test won't test things it's supposed to test in this case. lol	[reply]