Implement means to test asyncronous calls about js-test-driver HOT 12 CLOSED

To test asynchronous code you can use the JS Unit Mock Timeouts.

See this previous thread discussing it:
http://groups.google.com/group/js-test-driver/browse_thread/thread/13...

Or check out this Google Testing Blog entry:
http://googletesting.blogspot.com/2007/03/javascript-simulating-time-...

This approach works by overriding the setTimeout and setInterval
functions, and giving you a clock you can explicitly control in your
tests.

The main benefit of this approach is all your tests run instantly, you don't 
actually
need to wait for the timeout to complete! And there is no need for a timeout, 
which
could cause intermittent failures (due to a slow test machine for example.)

Thanks for the hint into this direction.

Because I always used QUnits possibilities to test asynchronous call, I never 
thought
about simply mocking them to create a synchronous sequence of calls. Even 
though this
seems quite intuitively the right thing to do now, I just never thought of it. 
The
jsUnit Mock Timeouts are a great addition to this.

This should cover everything I need to test using js-test-driver.

I like js-test-driver better every minute ;)

greetings Jakob  

I second the desire to get support for asynchronous tests. I've been using the 
JsUnit
mocker, and it works like a charm. Maybe it should just be rolled into 
JsTestDriver?

I noticed that there is an implementation for asynchronous tests in the latest 
JsTestDriver trunk.  I modified the QUnit adapter to support stop(), start(), 
and asyncTest().

The modified adapter works as of revision r364 if the patch from issue 125 is 
applied.

Is the revision in Comment #4 correct?  I looked at the patch and it doesn't 
seem to match up with the underlying source.  In fact I can't find any version 
of that file (QUnitAdapter.js) that lines up with the patch.  Did it come from 
a branch?

I ask this because I would love to use JSTD but I need to test async calls.  It 
is for doing integration tests rather than unit tests, but I still need a 
similar framework.

Never mind comment #5.  I upgraded to the head (r688) and the patch worked fine 
(assuming that the patch from issue 125 is applied first)

I'm sorry; I must have completely spaced when I wrote the revision number in 
comment #4.

I created a new plugin called QUnitTestRunnerPlugin 
<http://github.com/jivesoftware/QUnitTestRunnerPlugin> that I believe provides 
more robust support for running asynchronous tests with JsTestDriver and QUnit 
than QUnitAdapter does.  It also does not require patching JsTestDriver.  We 
are using QUnitTestRunnerPlugin to test production code at Jive Software.

The implementation of AsyncTestCase in release 1.2.2 works, just not as 
advertised in its current docs at 
http://code.google.com/p/js-test-driver/wiki/AsyncTestCase. Presumably the 
version in svn trunk works as described on that page.

Essentially, the 1.2.2 version passes a pool object to the tests in an 
AsyncTestCase rather than a queue object.

See also issue 171, which more-or-less duplicates this one.

Fully release in 1.3.0

I extended the adapter to add/update the methods to current QUnit trunk (as of 
15/09/11). Includes the patch above, adding QUnit async methods with some 
bugfixes.

You can find it here: https://github.com/progmedia/QUnit-to-JsTestDriver-adapter

Feel free to fork it and suggest patches. 

I'll soon be updating this repo with some scripts i'm working on to add support 
for external HTML fixtures, accessible from the DOM in tests, something I find 
sorely lacking in Js-Test-Driver.