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
In one of our projects, we've noticed that DeferCleanup() blocks are run after all AfterEach() blocks, without considering nesting. It may lead to a hard to find bug, when one of the top-level AfterEach() cleans up some resources, that a lower-level DeferCleanup() uses.
hey there - I appreciate the surprise factor here isn't great - but this is operating as intended. I should probably make the docs much clearer on this point but my intent with DeferCleanup is to provide a cleaner and simpler mechanism for cleanup and want to nudge users in the direction of favoring it over After* - you can mix the two in a given spec but then you'll end up with these edge cases.
Ginkgo could track things at the nesting level as you're describing but this will add complexity to the code (particularly some of the gnarly complexity around Ordered). Also, at this point, it would constitute a change in behavior so I'm not inclined to change the cleanup ordering.
In one of our projects, we've noticed that
DeferCleanup()
blocks are run after allAfterEach()
blocks, without considering nesting. It may lead to a hard to find bug, when one of the top-levelAfterEach()
cleans up some resources, that a lower-levelDeferCleanup()
uses.Here is a simple code for illustration:
It prints:
I would expect this order:
I've tested it on the latest
master
of this repository (cd418b7).Related Issue: #1284
The text was updated successfully, but these errors were encountered: