On Dec 27, 2004, at 6:45 PM, Brett Neumeier wrote:
>
> On Mon, 2004-12-27 at 10:07 -0700, Mike Clark wrote:
>> I tried writing some learning tests for Quartz a couple months back.
>> For what it's worth, I ran into the same timing issues.
>>
>> Before reaching for sleep(), I tried to refactor Quartz innards so
>> that
>> the internal clock could be programmatically advanced. Unfortunately,
>> a direct call to System.currentTimeMillis() was duplicated in many
>> places and even after consolidating all those calls through an
>> interface I was unable to mock the clock.
>
> I have done that as well. My Clock interface encapsulates
> System.currentTimeMillis(), new Date(), Calendar.getInstance(), and
> Thread.sleep(). There may be other standard API mechanisms that
> operate
> on the current system time, but those were the only ones in use in the
> code I was refactoring.
>
> Most of those were no problem, but pause (the method that encapsulates
> Thread.sleep()) was very difficult to fake. The problem is that when
> thread A calls pause, all other threads have to be given a chance to
> call pause before thread A is woken up. This is tricky because thread
> scheduling in Java is inherently unpredictable, and in Java 1.4 and
> earlier there is no way to determine whether any given thread is
> runnable or not. As a result the FakeClock is as reliable as most
> mechanisms for testing multi-threaded code: not perfectly.
>
> But the tests are an order of magnitude faster than they were when they
> just used Thread.sleep(), and they are as reliable as they were before,
> so that's good enough for me.
So, you were able to write tests for Quartz with these fakes?
--
Mike Clark
Clarkware Consulting, Inc.
http://clarkware.com
| Yahoo! Groups Sponsor | |
|
|
Yahoo! Groups Links
- To visit your group on the web, go to:
http://groups.yahoo.com/group/junit/
- To unsubscribe from this group, send an email to:
[EMAIL PROTECTED]
- Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
