Timer doesn't behave correctly

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Create a test that uses a GWT Timer (not Java Timer) that changes some state.
2. Schedule a timer with a very long delay
3. Right after the schedule call, add an assertion that verifies that the state 
has not been changed yet.
4. Run the test

Alternatively:
1. Unpack the attached maven project
2. Run mvn test

What is the expected output? What do you see instead?
The call to schedule() should return immediately, without any action.
The timer should be triggered after a while.

The call to schedule() returns instead only after firing the Timer event and 
therefore executing its run method.
If the scheduleRepeating() method is called, or if schedule() is called from 
within Timer.run(), the timer is fired exactly 5 times before giving the 
control back to the caller of the schedule method.

What version of the product are you using? On what operating system?
gwt-test-utils 0.38
GWT 2.4.0
JUnit 4.7

Original issue reported on code.google.com by sarcidia...@instart.co on 17 Aug 2012 at 10:29

Attachments:

• Timer_Bug.zip

[GoogleCodeExporter]

Simulating the real behaviour of GWT Timer would probably involve 
multi-threading, which might be complicated and overkill for testing purpose. 
I'll look at what would be a better option then triggering repeatingTimers a 
defined number of time in the same thread and let you know what will be done. 
If you have sugestion(s), it would be very nice to share ;-)

Original comment by gael.laz...@gmail.com on 20 Aug 2012 at 8:41

• Changed state: Accepted

[GoogleCodeExporter]

You're actually right, the real GWT Timer behavior is non-trivial.
I could think of some solution, but that would involve several additional calls 
in each test using Timers: an overkill indeed.

By the way, I think that rather than arbitrarily firing the timer, it would 
actually be better to use a java.util.Timer instance to fire it.
If a test expects Timer events, it most definitely is an asynchronous test, 
which will repeatedly call Thread.sleep in a loop, until some other thread 
changes a condition.
In this scenario, another thread running the timer events seems okay to me.

I took a look at the code, and I attempted a patch.
It's a huge project, so I'm not sure how to test the thing.

Original comment by djjeck on 20 Aug 2012 at 1:21

Attachments:

• timer.patch

[GoogleCodeExporter]

Your java.util.Timer based implementation looks great ! Many thanks !
At was thinking about doing this at the time I had to patch GWT Timer, but 
finally decided not to use multithreading since it could lead to some "not 
synchronised" resources issues (JavaScript is single-threaded, you don't have 
to carry synchronisation, but you'll have to pay attention when testing with 
gwt-test-utils).

But today I realize I was overthinking. It's better to have a correct behavior 
for Timers all the time and deal with synchronisation problems which might 
happen when they'd happen (quite rare situations)

So I applied your patch on github 
(https://github.com/gwt-test-utils/gwt-test-utils) and deployed a new 
0.40-SNAPSHOT version.

Before updating, you should carefully read this wiki page : 
https://github.com/gwt-test-utils/gwt-test-utils/wiki/Migration-to-0.40

It would be very nice if you could post some feedback here so I could close the 
issue ;-)

Original comment by gael.laz...@gmail.com on 25 Aug 2012 at 8:20

• Changed state: Fixed

[GoogleCodeExporter]

The new timer patcher breaks all our tests that relay in some way on a timer. 

As workaround I added a custom patcher that overrides the new implementation by 
the old one. So the tests are working as expected.

Original comment by Vieg...@gmail.com on 12 Sep 2012 at 8:12