On 5/23/13, Olemis Lang <[email protected]> wrote:
> 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 .
>

I'll clarify what I meant to say with the statement above because it
may be misunderstood .

Ensure that MP upgrade actions will not be performed due to the fact
that once MP upgrade method is executed it will notice everything is
up to date . Not doing so represents an error in MP system which has
to be asserted and reported as an (error | failure) .

>> 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.

Reply via email to