IE 8 doesn't have Array.prototype.indexOf so this breaks there.
Reverting until we can figure out a better way to solve across all
supported browsers.
This reverts commit 663fbd0cdb.
- Behaves similarly to to specResults
- Since suites were stored in an object instead of an array and the
current interface exposes this object, we now must keep track of suites
twice in the reporter. We cannot just construct the object lazily,
because then the object will not update with new suite results
like it does currently (see JsApiReporterSpec:148).
[#79533268]
- Focused runnables now walk up the tree to unfocus the first focused
ancestor. Because of the way the tree is constructed, this makes sure
that each focused runnable has no focused ancestors.
[#78289686]
Required duplicating some of the logic for constructing a suite from
describe so that we could mark a suite as focused in fdescribe, but
otherwise this prevents focused tests from being run more than once.
[#73742944]
- Fix bug where beforeAlls were being mutated in Suite#execute
- When Env.execute() receives a list of runnables, beforeAlls and
afterAlls are collected as beforeEachs and afterEachs. This allows
runnables to be specified in any order, regardless of if any of them
have before/afterAlls.
- Spec constructor takes a single function that returns both before and
afters, instead of two functions. This breaks the current interface
for constructing a Spec.
[#73742528]
This makes the specs green and appears to work for most cases. I have a
number of concerns about the implementation and would appreciate
ideas/feedback.
- Suite#addExpecationResult infers if it is coming from an afterAll fn
based on if the first child of the suite is finished. This assumes
that the first child of the suite is a spec (this appears to be true
as long as there is at least one spec in the suite)
- Suites behave like unfinished specs. Because suites will propagate
expectation failures to their children suites, the afterAll
expectation reporting appears to work for suites without specs
unless you have:
1) An otherwise empty suite with an afterAll
2) An afterAll'd suite whose first suite is empty (or whose first
suite's first suite is empty (and so on))
- Changed afterAllError to afterAllEvent, so it can accommodate both
errors and expectation failures. The reporter now receives a string
instead of the actual error object. The loss of the object doesn't
affect our reporters, but may be a nice-to-have for other reporters/
the future.
- The gap between the expectations caught in Suite and QueueRunner (who
triggers reporting via an injected callback) is an array injected into
QR by the Suite. The array is then flushed at some point (currently
after the attempt… functions). This works, but is a bit goofy.
[#73741654]
As described in issue #655, the handler of an interval cannot
successfully clear the same interval that generated it's invocation.
Solve this issue by changing the order in which interval's handlers are
called and then rescheduled to: first reschedule it and then call it.
The actual order (call first then reschedule) produces that, during the
execution of the interval's handler, the handler is not registered as
a function to run after a timeout or interval ("scheduledFunctions"),
because it was previously unregistered. Consequently, if the handler
calls clearInterval, that function wont be able to find the handler and
remove it completely.
