You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Introduce ContinueOnFailure for Ordered containers
Ordered containers that are also decorated with ContinueOnFailure will not stop running specs after the first spec fails.
Also - this commit fixes a separate bug where timedout specs were not correctly treated as failures when determining whether or not to run AfterAlls in an Ordered container.
Serial is a decorator that allows you to mark a spec or container as serial. These specs will never run in parallel with other specs.
49
-
Tests in ordered containers cannot be marked as serial - mark the ordered container instead.
49
+
Specs in ordered containers cannot be marked as serial - mark the ordered container instead.
50
50
51
51
You can learn more here: https://onsi.github.io/ginkgo/#serial-specs
52
52
You can learn more about decorators here: https://onsi.github.io/ginkgo/#decorator-reference
53
53
*/
54
54
constSerial=internal.Serial
55
55
56
56
/*
57
-
Ordered is a decorator that allows you to mark a container as ordered. Tests in the container will always run in the order they appear.
57
+
Ordered is a decorator that allows you to mark a container as ordered. Specs in the container will always run in the order they appear.
58
58
They will never be randomized and they will never run in parallel with one another, though they may run in parallel with other specs.
59
59
60
60
You can learn more here: https://onsi.github.io/ginkgo/#ordered-containers
61
61
You can learn more about decorators here: https://onsi.github.io/ginkgo/#decorator-reference
62
62
*/
63
63
constOrdered=internal.Ordered
64
64
65
+
/*
66
+
ContinueOnFailure is a decorator that allows you to mark an Ordered container to continue running specs even if failures occur. Ordinarily an ordered container will stop running specs after the first failure occurs. Note that if a BeforeAll or a BeforeEach/JustBeforeEach annotated with OncePerOrdered fails then no specs will run as the precondition for the Ordered container will consider to be failed.
67
+
68
+
ContinueOnFailure only applies to the outermost Ordered container. Attempting to place ContinueOnFailure in a nested container will result in an error.
69
+
70
+
You can learn more here: https://onsi.github.io/ginkgo/#ordered-containers
71
+
You can learn more about decorators here: https://onsi.github.io/ginkgo/#decorator-reference
72
+
*/
73
+
constContinueOnFailure=internal.ContinueOnFailure
74
+
65
75
/*
66
76
OncePerOrdered is a decorator that allows you to mark outer BeforeEach, AfterEach, JustBeforeEach, and JustAfterEach setup nodes to run once
67
77
per ordered context. Normally these setup nodes run around each individual spec, with OncePerOrdered they will run once around the set of specs in an ordered container.
Copy file name to clipboardexpand all lines: docs/index.md
+10-1
Original file line number
Diff line number
Diff line change
@@ -2264,7 +2264,11 @@ Lastly, the `OncePerOrdered` container cannot be applied to the `ReportBeforeEac
2264
2264
2265
2265
Normally, when a spec fails Ginkgo moves on to the next spec. This is possible because Ginkgo assumes, by default, that all specs are independent. However `Ordered` containers explicitly opt in to a different behavior. Spec independence cannot be guaranteed in `Ordered` containers, so Ginkgo treats failures differently.
2266
2266
2267
-
When a spec in an `Ordered` container fails all subsequent specs are skipped. Ginkgo will then run any `AfterAll` node closures to clean up after the specs. This failure behavior cannot be overridden.
2267
+
When a spec in an `Ordered` container fails all subsequent specs are skipped. Ginkgo will then run any `AfterAll` node closures to clean up after the specs.
2268
+
2269
+
You can override this behavior by decorating an `Ordered` container with `ContinueOnFailure`. This is useful in cases where `Ordered` is being used to provide shared expensive set up for a collection of specs. When `ContinueOnFailure` is set, Ginkgo will continue running specs even if an earlier spec in the `Ordered` container has failed. If, however a `BeforeAll` or `OncePerOrdered``BeforeEach` node has failed then Ginkgo will skip all subsequent specs as the setup for the collection specs is presumed to have failed.
2270
+
2271
+
`ContinueOnFailure` can only be applied to the outermost `Ordered` container. It is an error to apply it to a nested container.
2268
2272
2269
2273
#### Combining Serial and Ordered
2270
2274
@@ -4819,6 +4823,11 @@ The `Ordered` decorator applies to container nodes only. It is an error to try
4819
4823
4820
4824
When a spec in an `Ordered` container fails, all subsequent specs in the ordered container are skipped. Only `Ordered` containers can contain `BeforeAll` and `AfterAll` setup nodes.
4821
4825
4826
+
#### The ContinueOnFailure Decorator
4827
+
The `ContinueOnFailure` decorator applies to outermost `Ordered` container nodes only. It is an error to try to apply the `ContinueOnFailure` decorator to anything other than an `Ordered` container - and that `Ordered` container must not have any parent `Ordered` containers.
4828
+
4829
+
When an `Ordered` container is decorated with `ContinueOnFailure`then the failure of one spec in the container will not prevent other specs from running. This is useful in cases where `Ordered` containers are being used to have share common (expensive) setup for a collection of specs but the specs, themselves, don't rely on one another.
4830
+
4822
4831
#### The OncePerOrdered Decorator
4823
4832
The `OncePerOrdered` decorator applies to setup nodes only. It is an error to try to apply the `OncePerOrdered` decorator to a container or subject node.
returntrue//...or, a run-once node at our nesting level was skipped which means this is our last chance to run
248
258
}
249
-
casetypes.SpecStateFailed, types.SpecStatePanicked: // the spec has failed...
259
+
casetypes.SpecStateFailed, types.SpecStatePanicked, types.SpecStateTimedout: // the spec has failed...
250
260
ifisFinalAttempt {
251
-
returntrue//...if this was the last attempt then we're the last spec to run and so the AfterNode should run
261
+
ifg.continueOnFailure {
262
+
returnisLastSpecWithPair||failedInARunOnceBefore//...we're configured to continue on failures - so we should only run if we're the last spec for this pair or if we failed in a runOnceBefore (which means we _are_ the last spec to run)
263
+
} else {
264
+
returntrue//...this was the last attempt and continueOnFailure is false therefore we are the last spec to run and so the AfterNode should run
265
+
}
252
266
}
253
267
if!terminatingPair.isZero() { // ...and it failed in a run-once. which will be running again
0 commit comments