openstack team mailing list archive
-
openstack team
-
Mailing list archive
-
Message #08474
Re: cfg usage - option registration, global objects
Really not trying to derail, but
"Mark McLoughlin" <markmc@xxxxxxxxxx> said:
>
> [..]
>> > Also, these global objects force us to do a bunch of hacks in unit
>> > tests. We need to do tricks to ensure the object is initialized as
>> > we want. We also need to save and restore its state between runs.
>> >
>>
>> I don't agree with the statement that they force "a bunch of hacks,"
>> clearing state is a perfectly normal thing to do, it is done for any
>> servers that get started, any mocks that are made, and every test
>> database. Making sure that modifications to a configuration object are
>> cleaned up is no different: there is no "save and restore" just always
>> start from a blank slate and set things as required, same as in the
>> non-global model.
>
> Creating mocks, DB connection objects or re-starting servers on each
> test run is different from trying to restore a global object to its
> state before a test run.
>
> The CONF object is initialized the first time the config module is
> imported. Each test run you need to attempt to reset the object back to
> its original pristine state. Compared to just creating a config object
> for each run, I do think that's a hack.
>
While I agree with what Mark is saying above, I really must
point out that any significant shared state among unit tests is
either a hack, or a smell, or most charitably, the wrong kind of
test to run with unit tests.
Any teardown that isn't just handled by the garbage collector is
a good clue that we're doing something suboptimally.
References