All timeouts and intervals set during a tick were being scheduled to run
at delay + end-of-tick, instead of delay + time-of-outer-timeout.
Scheduled run-at times were shifted because currentTime was being
incremented before executing scheduled functions.
Additionally, the execute loop was iterating over a functions-to-run
array, created from scheduledFunctions before starting. Any changes to
scheduledFunctions were being ignored during the tick, and the next tick
would ignore any functions which should have been executed in the past.
The commit is a rewrite of DelayedFunctionScheduler, preserving the
public interface. Execution of scheduled functions updates currentTime
on each iteration, and each time takes the functions with the lowest
runAtMillis from the schedule, if they aren't higher than endTime.
When an async spec throws a (sync) exception for some reason, the
exception was correctly caught and reported by Jasmine but the timeout
timer continued to run in the background.
For instance, running the (rather stupid) example below would report
the exception immediately but would also make the process loop for 5s
(and report the exception depending on the reported being used).
describe('exception', function () {
it('is caught but timer continues to run', function (done) {
throw new Error('Oh no!');
});
});
This happened because the timout timer is set in Spec while the
"try... catch" block is in the queue runner. The "callDone" function
of "timeoutable" that resets the timer was thus not called.
The commit simply introduces a "try... catch" block within the
`timeoutable` function to ensure that "callDone" gets called even
when an exception is thrown.
- Passing in a 'negativeCompare' will cause that function to be used when it is a 'not' assertion
- Otherwise, the reversal of the compare's result will be used instead
[finishes #59703824]
- Users can no longer spelunk the spec tree from topSuite
- Users no longer have access to currentSuite/currentSpec
- Other miscellaneous (arguably less useful) methods have also been tucked
away into the closure, like suiteFactory
- Specs are passing by default unless told otherwise
- Getting the result.status of a spec before the spec has run is now
undefined instead of pending
[finishes #59422744]
On a very large test suite (8000 specs), a significant amount
of time is spent just drawing the spec dots. Some sort of
worse-than-linear artifact that summons itself only when you
have 8000 floated elements trying to hang out together.
This performance penalty is not seen with inline-block.
In Chrome 29:
Floated dots: 16.795s
Inline-block dots: 2.774s
Setting the dots to 'display: none;' takes about the same time
as the inline-block figure, so this is probably a low enough bound
(no need for chunked rendering or who knows what).
Sheel Choksi