- execute beforeAll/afterAll once per suite instead of once per child
when running focused specs/suites Fixes#773
- refuse to execute an order if it would cause a suite with a beforeAll
or afterAll to be re-entered after leaving once
- report children of an xdescribe similarly to how they would be
reported if they were themselves x'd out Fixes#774
- only process the tree once instead of figuring it out again at each
level
[finishes #87545620]
Fixes#776
- If the mock clock was installed in a beforeAll, the QueueRunner would use the mock clock for its own clock. If the mock clock was ticked more than the default timeout, async specs would timeout.
[fixes#783#792]
- This requires passing if runnables are set to the Suite. Hopefully in
the future we will change how focused runnables and *Alls interact so
this is no longer necessary.
[#732]
- 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]
Yo, this probably isn't the best behavior. Rspec and Ginkgo definitely
do not exhibit this behavior when you nest focused runnables inside
other focused runnables. We thought fixing it, but it seems like a
nontrivial refactoring would be necessary to clean this up.
[#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]
We found that this test was always passing and had strange interactions
with the ordering of other specs. Rewriting it to explicitly finish the
afterAll after a specified interval makes it fail correctly.
[#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]
If an async test has timed-out, there could still be some expectations
that are scheduled to run after the fact in which case curerntSpec will
be null. Rather than the type error that would result, we now indicate
that 'expect' was used at an unexpected time.
This also helps cases where an 'expect' is being used at a top-level,
showing an error message in the console for this case as well.
[fixes#602]
Gregg Van Hove