FLUID-5911: Review and update qunit-composite.js for newer versions of QUnit...

Description

In working with Karma, I discovered a clear point at which qunit-composite.js will no longer work with newer versions of QUnit. Although there may be other problems, the immediate error is a result of the addEvent function being called from qunit-composite.js. That function was made private between v1.1.4 and v1.15 of QUnit.

I was trying to use the QUnit.testSuites function to load HTML fixtures in Karma. There is a very old release of the karma qunit plugin that uses an old enough version of QUnit to be compatible, I will try that in the short term.

However, this is just one symptom of a looming problem. We have pinned a part of our tests to a copy of an aging version of QUnit. Long term, we should move to having QUnit as a clear dependency, and should regularly test updates.

Comments

• Tony Atkins [RtF] commented 2016-06-01T04:12:42.962-0400

  I encountered problems related to the age of our QUnit when trying qunit-tap per a suggestion from @@Antranig Basman.

  They have specifically had problems with QUnit 1.12.0 (the version we keep a local copy of) for a few years running. 1.13.0 or higher seems fine:

  https://github.com/twada/qunit-tap

  I am trying to use an older version of qunit-tap, but this really doesn't seem sustainable in the longer term.

• Tony Atkins [RtF] commented 2016-06-01T04:52:04.394-0400

  We should review in Toronto, from what I can see in my testing, the older version of qunit-tap only works with QUnit 1.10.0, and cannot be used with our forked copy of 1.12.0.

  The next version of qunit-tap explicitly added details about the fact that 1.12.0 isn't supported, so it's likely that it never worked with QUnit 1.12.0.

• Tony Atkins [RtF] commented 2016-10-27T07:40:59.996-0400

  Here's another example that came up in a recent PR:

  https://github.com/GPII/gpii-launcher/pull/1#discussion_r85289741

  In later versions of 1.x, QUnit started migrating to a new approach, using QUnit.test with an explicit call to QUnit.stop() instead of asyncTest. As I refresh my memory with their docs periodically, I started adopting this transitional approach a while back. It works with node-jqUnit as well.

  However, in QUnit 2.x, there's a new "async" function that is used within a QUnit.test function instead of calling stop and start. I just wrote a quick test script to confirm, all previous variations are disallowed in QUnit 2.x. Only the new async method is supported.

  Even if we decide that we can't leave 1.12.0 behind, we need to make the difference clearer. In the node-jqunit docs, we currently point people at the QUnit docs as though they reflect what can be done with node-jqunit. At a minimum, we should update node-jqunit and any QUnit docs within infusion to indicate the QUnit versions we support, and we should point to QUnit documentation that corresponds to what we support. Here for example are the building blocks of the docs for 1.12.0:

  https://github.com/jquery/api.qunitjs.com/tree/3d3576ad22bcaf21cde0769250f7043e1197a8b1

• Tony Atkins [RtF] commented 2016-10-27T07:43:14.517-0400

  We do have at least some guidance for Infusion itself (although that incorrectly claims that QUnit 2.x has not been released):

  https://github.com/fluid-project/infusion-docs/blob/98fa4e0a222108d0acd337118ba645083d43cfee/src/documents/jqUnit.md

  Adding that kind of disclaimer to node-jqUnit is fine for now, but both should be updated to point to appropriate QUnit documentation.

• Tony Atkins [RtF] commented 2016-10-27T07:52:05.669-0400

  Here for reference are the three approaches in a single file: http://pastie.org/10951023

  The first two are commented out as I was testing with QUnit 2.x, which throws a script error if either of the earlier variations is used.