On 5/23/13, Anze Staric <[email protected]> wrote: [...] >> - Is this closer to the code run in production ? > In production, each environment is associated with a separate > database.
Each global environment ... but what about product environments ? They all should share the same database . [...] >> 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 > > Please note, that reset_db does not downgrade the database, it just > removes the data from the tables. If env.upgrade is run again, it > fails (multiproduct plugin version is deleted from the system table, > but the tables are modified. If this is the point then I'd rather prefer to keep MP version in system table after invoking env stub `reset_db` at testing time ... > When upgrade is run again, it figures, > that it needs to perform all upgrades and tries to add field product > to table ticket, but this fails, because the field is still there, it > was not deleted in reset_db). > ... and ensure that MP upgrade procedure will not be triggered if DB schema is up to date , which represents a bug indeed . > To minimize the impact of the patch, I really think this should be solved by modifying test code (e.g. EnvironmentStub class ) rather than monkey patching a class in the SUT . More important than making tests pass is the fact that test success really implies that the SUT is working as expected . [...] -- Regards, Olemis.
