-
Notifications
You must be signed in to change notification settings - Fork 59
Conversation
Hmm... This might not be good enough. Because of how beforeAll works (it waits until an it block is found before running), something could modify a parent context after the children are created. Either I need to change beforeAll or context needs to support dynamic parents. (I might need to change beforeAll for other reasons, so I need to think on this a bit.) |
Actually, this should be fine. It makes more sense to change how beforeAll works than to try and dig up the right context to pass to it. Especially since it looks like beforeAll and afterAll might not be consistent in when they run at the moment. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Implementation looks good. We should add a test case to pin the behavior of a parent context being written to after a child context is created. As written right now, the new parent value won't be available through the child context.
I intentionally left out that test case when I was writing this since that behavior wasn't actually decided yet. I think I'm leaning towards keeping the current behavior though as there should be no cases where you can mutate a parent context while a child is in scope and this is the simpler option. |
Add a Context class to pass along to each test node. Follows #109. Part of #108.