Metadata
- Source
- FLUID-5070
- Type
- Bug
- Priority
- Major
- Status
- Open
- Resolution
- N/A
- Assignee
- Antranig Basman
- Reporter
- Justin Obara
- Created
2013-06-26T12:00:08.390-0400 - Updated
2015-06-15T10:34:34.331-0400 - Versions
-
- 1.5
- Fixed Versions
- N/A
- Component
-
- Testing Infrastructure
Description
Steps to reproduce:
1) Run the SettingsPanels unit tests.
http://build.fluidproject.org/infusion/tests/component-tests/uiOptions/html/SettingsPanels-test.html
All the tests should pass
2) Click the "Rerun" link beside each of the tests to run them individually.
Notice that from the 3rd one on, they start to have failures, due to the tests being run twice.
Comments
-
Antranig Basman commented
2013-06-26T12:05:00.105-0400 The problem lies with the following block of code, which assumes that an asynchronous test issued to QUnit will always begin to execute asynchronously. Sometimes QUnit will finish the test completely before the the following queue check executes, which then causes the testing framework to faultily try to reinstantiate the entire tree when it reaches the "noteTest" directive:
IoCTestUtils.js lines 466-479
// Note that this test relies on an implementation detail of qunit. For those
// tests which fail the "validTest" test due to being filtered out in the UI,
// they result in no material placed in the queue. We escape the case where they
// might enter the queue and immediately leave it as a result of only ever issuing
// asynchronous tests
var oldLength = QUnit.config.queue.length;
jqUnit[testType](fixture.name, testFunc);
if (QUnit.config.queue.length === oldLength) {
fluid.log(fluid.logLevel.IMPORTANT, "Skipped test " + fixture.name);
}
else {
fluid.log(fluid.logLevel.IMPORTANT, "Successfully queued test " + fixture.name);
fluid.test.noteTest(testCaseState.root, 1);
}