#15642 closed defect (fixed)
CancelError exception thrown by robot
Reported by: | Douglas Hays | Owned by: | haysmark |
---|---|---|---|
Priority: | undecided | Milestone: | 1.8 |
Component: | TestFramework | Version: | 1.8.0b1 |
Keywords: | Cc: | ||
Blocked By: | Blocking: |
Description
Run dijit/tests/robot/typematic.html (I tried both Chrome 20 and IE9).
After the first test, the robot calls seqPromise.cancel() which causes a CancelError? exception, although all tests pass.
Attachments (2)
Change History (10)
comment:1 Changed 9 years ago by
Milestone: | tbd → 1.8 |
---|---|
Owner: | set to haysmark |
Status: | new → assigned |
comment:2 Changed 9 years ago by
comment:3 Changed 9 years ago by
This is due to the code I added in [29101], and is actually happening on every test. I don't know why it only displays the error the first time.
[29101] changed robot to use a chain of promises to execute all the "commands" registered via sequence().
It's actually now redundant for the typematic test and other tests to create and return their own Deferred object. It would be better if they just returned the seqPromise promise chain. However, they create their own Deferred for historical reasons, and that's leading to tricky timing between when the tests' Deferred resolves vs. when the chain of promises resolves.
Every robot test fixture is something like:
var d = new doh.Deferred(); ... robot.sequence(d.getTestCallback(function(){ doh.t(...); }), 500); return d;
The sequence of actions is:
- all but the last action in the seqPromise queue runs, and the 500ms delay runs too
- now the seqPromise queue has 1 item: the callback above
- the callback starts and finishes running
- getTestCallback() resolves the Deferred "d", triggering this text fixture to end and the new test fixture to start running
- before() advice runs, and tries to clear any leftover actions from the previous test
The problem is that even though the final callback function has finished executing, seqPromise hasn't quite yet been marked as fulfilled.
comment:4 Changed 9 years ago by
Though not eloquent, a simple setTimeout (and saving the current seqPromise in a local for deferred execution) seems to solve the issue.
comment:5 Changed 9 years ago by
Alternatively, as Bill suggested, we could add the setTimeout to runner.js. I was initially worried about putting the setTimeout in robot.js but if we save the seqPromise it should be OK. I attached both versions; if there are no objections, I will commit the robot.js version.
comment:6 Changed 9 years ago by
I'm OK with that.
For the record, for 2.0 I'd like to have a cleaner API for writing robot tests. I filed #15644 to track that.
I tried duplicating the first test and still got only one error. We only started noticing it now because of the new promise instrumentation.