On 5/22/13, Gary Martin <[email protected]> wrote: > On 22/05/13 18:23, Olemis Lang wrote: >> On 5/22/13, [email protected] <[email protected]> wrote: >>> Author: astaric >>> Date: Wed May 22 15:47:48 2013 >>> New Revision: 1485255 >>> >>> URL: http://svn.apache.org/r1485255 >>> Log: >>> Force trac to use separate db connections for different environments >>> when >>> running tests. >>> >>> Unittests in python2.7 run in the same process and share the same >>> connection >>> pool. This basically means that all tests share the same in-memory >>> database, >> yes but , considering the fact that tests are executed in sequential >> order , there's no harm done for well-written test cases >> >>> and calling reset_db in teardown methods destroys data prepared in >>> __init__ >>> of other tests. >> Test data must not be prepared on __init__ . Disposing test data in >> tearDown is quite convenient to isolate test case execution . If test >> data is created by test case #1 and it's not disposed afterwards then >> it might be messing around until the end of the test run thus >> polluting test reports by introducing false negative results . This is >> a terrible headache wrt test code , which btw , I'm suffering now with >> RPC plugin test suite ... so please, do not alter that behavior (i.e. >> clean in-memory DB expected as TC pre/post-condition ) . >> >> >>> Trac tests do not do prepare data in __init__, >> indeed , for a good reason ... >> >>> but when run >>> with a product env, which stores config values to database, this >>> behavior >>> causes multiple tests to fail. >>> >> then why not to ensure that such values are configured at the >> beginning of each test case inside setUp method . >> >>> We workaround this issue by monkey patching trac's ConnectionPool. We >>> force >>> it to establish a separate connection for each DatabaseManager. >>> >> ... this starts to make sense to me ... but, isn't it the very same DB >> in the end ? >> >> in any case , please beware of the facts above in spite of emitting >> test reports we can trust . >> >> [...] >> > > It doesn't make sense to me yet. What data is set up in __init__s at the > moment
none that I'm aware of ... > and why is this not done in the setUp method? > the question I'd rather ask is why is it compulsory to monkey patch ConnectionPool methods ? In general , the more we monkey patch real classes to make test cases pass , we'll be less confident of test results because such modifications will not be available on production and might have non-trivial side-effects at testing time obscuring behaviors that might happen in practice . I'd rather prefer to (always | sometimes) replace them with mock objects (e.g. EnvironmentStub , Mock ...) > I'd best get searching! > ;) -- Regards, Olemis.
