From 903be81ba5a3f47631e6cb0e7c72c12fe47a6746 Mon Sep 17 00:00:00 2001 From: Onsi Fakhouri Date: Wed, 3 May 2023 09:02:24 -0600 Subject: [PATCH] Document run order when multiple setup nodes are at the same nesting level fixes #1172 --- docs/index.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/index.md b/docs/index.md index 7f9528d82..2978cfee1 100644 --- a/docs/index.md +++ b/docs/index.md @@ -404,7 +404,7 @@ var _ = Describe("Books", func() { Using container nodes helps clarify the intent behind our suite. The author name specs are now clearly grouped together and we're exploring the behavior of our code in different contexts. Most importantly, we're able to scope additional setup nodes to those contexts to refine our spec setup. -When Ginkgo runs a spec it runs through all the `BeforeEach` closures that appear in that spec's hierarchy from the outer-most to the inner-most. For the `both names` specs, Ginkgo will run the outermost `BeforeEach` closure before the subject node closure. For the `one name` specs, Ginkgo will run the outermost `BeforeEach` closure and then the innermost `BeforeEach` closure which sets `book.Author = "Hugo"`. +When Ginkgo runs a spec it runs through all the `BeforeEach` closures that appear in that spec's hierarchy from the outer-most to the inner-most. If multiple `BeforeEach` nodes appear at the same nesting level they will be run in the order in which they appear in the test file. For the `both names` specs, Ginkgo will run the outermost `BeforeEach` closure before the subject node closure. For the `one name` specs, Ginkgo will run the outermost `BeforeEach` closure and then the innermost `BeforeEach` closure which sets `book.Author = "Hugo"`. Organizing our specs in this way can also help us reason about our spec coverage. What additional contexts are we missing? What edge cases should we worry about? Let's add a few: