Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
added optional timeout to phantomjs runner #415
Correct, that is the example I ran into.
Has this proven to be an actual problem? Or just in theory?
Afaik QUnit has a built-in timeout handler that should be more than enough. It is implemented on the test level (not the global level) so we may want to keep this global timeout as well (at the phantomjs level here), but I think in most cases you'll want to keep the global timeout in phantomjs disabled and instead use the one in QUnit so you don't end up with incomplete output when it is aborted (depending on the formatter and whether the formatter lives in the browser or in node, you could end up with invalid json/xml or whatever).
It has the advantage of letting everything else still run (instead of aborting everything). That way you have a more complete list of failures instead of just the first one (makes for more efficient working when fixing them by being able to fix more than one at once instead of having to re-run it after each one to find out the next possible failure).
Another advantage is that the per-test timeout scales better as you don't have to update it periodically as your test suite grows (fast tests but more of them).
As said, the phantomjs timeout can still be useful so we should definitely keep it. But I just wanted to make sure you're also aware of
I didn't know about QUnit.config.testTimeout, and I agree with Timo's reasons for