Global Variable and BeforeSuite

551 views
Skip to first unread message

jbh...@gmail.com

unread,
Apr 21, 2014, 12:25:22 PM4/21/14
to ginkgo-a...@googlegroups.com
At startup, I'm setting a global variable which is a testing context for Google AppEngine. The global variable seems to be properly set in It clauses, but seems to be nil in Describe and Context clauses. I've tried both BeforeSuite and SynchronizedBeforeSuite. Is this intended behavior?

I can work around this to some extent by referencing the AppEngine context only in It clauses. But, it does seem to make the BDD structure a bit awkward.

Jeff

Onsi Fakhouri

unread,
Apr 21, 2014, 1:39:00 PM4/21/14
to ginkgo-a...@googlegroups.com
This is behaving exactly as intended.  It's important to distinguish between things that happen when your program loads up (let's call this construction-time) and things that happen when the test suite runs (let's call this run-time).

During construction-time (this is before the TestXXX bootstrap function runs) all your Context and Describe blocks are evaluated as Ginkgo builds up a tree structure in the background - this tree structure basically includes references to all the functions you've passed into your various Its, Befores, etc...  These functions aren't evaluated yet, they're simply saved off.  Ginkgo then takes this tree structure and converts it into a flat list of tests to be run.

During run-time, Ginkgo first runs the BeforeSuite function, then walks this flat list of tests, running the functions in your Its and Befores/Afters.

So, your global testing context for Google AppEngine, which is set up in a BeforeSuite function, will only be available to functions in your Its and Befores/Afters.  It is not available in your Describe and Context clauses because it hasn't been set up yet.  This is typically what you want: since the Describes and Contexts are evaluated at construction-time they aren't rerun between each test so modifications made to globals within those clauses will leak across tests non-deterministically and result in test pollution.  To avoid this you should always set/modify/read these sorts of variables within a run-time clause.

If you point me to some of your code I'd be happy to give you some more specific pointers/insight into your specific use-case.

Onsi

Jeff Huter

unread,
Apr 21, 2014, 1:52:44 PM4/21/14
to ginkgo-a...@googlegroups.com
Thanks for the explanation.  Very helpful.  I just confirmed moving this code to Befores works.  This should enable me to structure the tests in a reasonable fashion.  Thanks again.

Jeff
Reply all
Reply to author
Forward
0 new messages