Bug Tracker

#5085 closed feature (invalid)

Opened August 20, 2009 12:53PM UTC

Closed February 05, 2010 09:39PM UTC

qunit: prevent slow script warnings in long testsuites

Reported by: dwt Owned by: joern
Priority: major Milestone:
Component: qunit Version:
Keywords: qunit, slowness Cc:
Blocked by: Blocking:
Description

We've added this patch to our QUnit to prevent slow script warnings in IE and Firefox:

Index: agilo_pro/htdocs/js/tests/qunit/testrunner.js
===================================================================
--- agilo_pro/htdocs/js/tests/qunit/testrunner.js	(Revision 1844)
+++ agilo_pro/htdocs/js/tests/qunit/testrunner.js	(Arbeitskopie)
@@ -281,8 +281,14 @@
 }
 
 function process() {
+	var index = 0;
 	while(config.queue.length && !config.blocking) {
 		config.queue.shift()();
+		// prevent slow script warnings in long test suites
+		// do it only every tenth test though to minimize the performance hit this workaround has
+		if (index > 10)
+			return setTimeout(process, 0);
+		index++;
 	}
 }

This combines very nicely with #4857 as it allows one to disable auto reloading the testsuite during testsuite execution, instead of only after it has run through.

Another benefit of this is that in browsers that only have one JS Engine, so executing the tests in the background doesn't block all other tabs / windows completely.

Attachments (0)
Change History (3)

Changed August 20, 2009 08:19PM UTC by joern comment:1

To make the testrunner even more responsive, each update should be interleaved with a timeout:

function process() {
	if (config.queue.length && !config.blocking) {
		config.queue.shift()();
		setTimeout(process, 13);
	}
}

The drawback here is that it actually degrades performance. Probably due to various DOM updates being skipped when the UI is blocked. That shouldn't stop this patch from being applied, but QUnit also needs some performance tuning.

Changed August 20, 2009 09:20PM UTC by dwt comment:2

We tried that too, but this degraded the performance of our testsuite by about 300% - which was unacceptable to us.

Thats why we choose to only set the timeout every 10th run through.

Regards,

Martin

Changed February 05, 2010 09:39PM UTC by john comment:3

resolution: → invalid
status: new → closed

We're moving QUnit-related bugs off to the new QUnit issue tracker:

http://github.com/jquery/qunit/issues

Please re-post the issue there.