On 5/23/13, Anze Staric <[email protected]> wrote: > On Thu, May 23, 2013 at 2:25 PM, Gary Martin <[email protected]> > wrote: >> Apart from this kind of case, I was also thinking that it might be better >> to >> get the reset_db method overridden so that it resets the database back to >> the clean form that we want. > > I like the idea,
it's nice , even if I'd prefer to stick to patch the connection pool in TC setUp and revert in tearDown > but how to we get the database to a clean state after > it has been migrated to multiproduct in setUp? that's exactly why MP upgrade should be performed once for each unit test . After doing so , execute assertions on the SUT and get rid of it afterwards ... the next TC will start from scratch and recreate everything once again > Do we hard code which > fields and tables need to be removed and which keys do need to be > modified? > Your point is valid . This is a real difficulty . In recent functional TCs I've written for RPC plugin what I do is to ensure that the names of the products created for testing will never be the same . Then in tearDown I just clear bloodhound_product table (except entry for default product) and isolation across product environments (combined with GUID for products) will ensure there will be no side-effects propagated beyond test case lifetime . There's no need to do so for unit tests . > I still think that forcing the trac to use a separate database for > separate environments is a cleaner solution. An alternative to monkey > patching ConnectionPool is to modify EnvironmentStub to use > DatabaseManager that creates one connection to database per product > (if we are using in memory database). > I'd be ok with that *if* - the patch is really needed - it will only affect a limited (and relevant) subset of the test suite -- Regards, Olemis.
