If QUnit/Jasmine load too late, Phantom doesn't set up callbacks and thus hangs #1

Closed
mark-rushakoff opened this Issue Apr 7, 2012 · 4 comments

Comments

Projects
None yet
2 participants
Owner

mark-rushakoff commented Apr 7, 2012

The scripts detect QUnit or Jasmine in Phantom's onResourceLoaded callback; if the QUnit script is the last resource to load, the callback can be triggered before the script is actually evaluated. By the time we realize that this has happened, we may have already lost our opportunity to attach our hooks -- the test runner may have even finished by that point!

The only client-side workaround I can think of is:

  • Load your test runner very early, and include enough external scripts so that one of them will trigger onResourceLoaded after window.QUnit or window.jasmine is available

It looks like running your tests from a file:// protocol will also do the trick, when that is an option.

Phantom-side workarounds may include:

  • setInterval in onLoadStarted
  • Query the DOM inside the page load callback
  • Wait for a future version of Phantom that has a better/more appropriate callback?

@ghost ghost assigned mark-rushakoff Apr 7, 2012

mark-rushakoff added a commit that referenced this issue Apr 7, 2012

Contributor

RReverser commented Sep 5, 2013

Just thinking about more stable solutions...

Actually, I had to solve problem of catching overall done callback in QUnit and, later, Mocha, in another project long time before finding your repo.

And workaround that worked for me was adding empty test case to the end of page that simply executed ok(true) and, after this, called phantom (I used experimental callPhantom + page.onCallback binding there, but we can consider setting global variable as well).

Since all the engines run tests in order (all at once or splitted into (1) failed and (2) succeeded groups), our fake test case always comes last and we can easily return all the required information about real tests.

What do you think?

Owner

mark-rushakoff commented Sep 5, 2013

@RReverser I like that solution, but I wonder if there are any explicit guarantees about test order, or if we would be relying on implicit behavior that may change in the future. I'm wondering if a hybrid approach makes sense -- inject a test and poll if test is finished -- but I don't think I've written any Javascript this year, so my judgement on these topics will be under-informed at best.

Contributor

RReverser commented Sep 6, 2013

@mark-rushakoff Well, I didn't find any popular test engines that would run tests in random order so far. At least, those listed in scripts definitely have this behavior and I don't see any reasons why they would want to decide to mess everything up. Going to give it a try and see if this approach works for our cases.

@mark-rushakoff mark-rushakoff closed this in #10 Sep 7, 2013

Contributor

RReverser commented Sep 7, 2013

Hm, was it closed for Jasmine too?

mark-rushakoff added a commit that referenced this issue Sep 9, 2013

Merge pull request #11 from RReverser/master
Removed info about closed issue #1 from README
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment