Closed Bug 946728 Opened 6 years ago Closed 6 years ago
Drop unit tests fail
No description provided.
Assignee: nobody → crdlc
Status: NEW → ASSIGNED
Attachment #8343077 - Flags: review?(francisco.jordano) → review+
I am going to disable all dragdrop tests because they are failing and I don't know why it is happening. We have to investigate the root case.
Summary: DragDrop unit tests are very slow and sometimes fires timeouts → DragDrop unit tests fail
Hi guys, any suggestion why it could be happening? I haven't touched that code some months ago
ENSURE_DRAG_END_DELAY is 1sec, it's what causes the delay in the "end(" part of the test. One simple change could be to use sinon's fake timers (`this.sinon.useFakeTimers()` in setup) and use `this.sinon.clock.tick(1000)` at the end of the "end" function. The "move(" call takes 400ms and the reason is probably the same, although I don't find where it is (the onpageready event is more difficult to track ;) ). You could try to add `this.sinon.clock.tick(400)` at the end of the "move" function and see how this works ;) You might need other calls to "this.sinon.clock.tick()" (without a value) because we have a lot of setTimeout without values, but maybe the other calls would make this work without this.
> Hi guys, any suggestion why it could be happening? I haven't touched that code some months ago It's like this since months :p
but today every time jijij
note: I don't know why they fail (they don't here), but my comment 5 explains why they're slow. But this could be the cause (Travis does not like setTimeouts)
I tried to do my comment 5 but it doesn't work right now. I'd like to try to redo the tests without loading page.js, it should be easier to debug... But is is a big work :(
Well, I've implemented it  and each test runs in 50-80ms in my pc. We will see what happens in Travis  https://github.com/crdlc/gaia/commit/3d0dd7e8ac839b0fb2871e5a7b53dfb7769b26c6
Does not work at all yet, but this is for reference.
(In reply to Cristian Rodriguez (:crdlc) (OFF 12/06 -- 12/10) from comment #10) > Well, I've implemented it  and each test runs in 50-80ms in my pc. We > will see what happens in Travis > >  > https://github.com/crdlc/gaia/commit/3d0dd7e8ac839b0fb2871e5a7b53dfb7769b26c6 It's still using timeouts, so based on past experience this will trigger intermittents for sure.
for sure, it was just a test. In my pc is 50ms instead of 1400ms. You can follow working on your patch and when I will come back I can be your reviewer ;)
Julien, please, feel free to take this bug because you created a patch to fix this. I prefer to focus on download manager bugs right now
Assignee: crdlc → nobody
Status: ASSIGNED → NEW
Taking it, not sure if I'll have the time to work on this but we'll see. Don't hesitate to steal if you want to work on this.
Assignee: nobody → felash
Assignee: felash → crdlc
Status: NEW → ASSIGNED
I've killed the asynchrony :) Before 11.05s -> After 0.82s
Comment on attachment 8386710 [details] 16948.html r=me thanks a lot, this was today's good surprise :)
Attachment #8386710 - Flags: review?(felash) → review+
:), ok going to github, thx
Will probably fix bug 938651 too
Merged in master: https://github.com/mozilla-b2g/gaia/commit/f73cf17b9ad945084fdf852244fe332f261cc540
Status: ASSIGNED → RESOLVED
Closed: 6 years ago
Resolution: --- → FIXED
Target Milestone: --- → 2.0 S2 (23may)
Target Milestone: 2.0 S2 (23may) → 1.4 S3 (14mar)
You need to log in before you can comment on or make changes to this bug.