incubator-bloodhound-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Olemis Lang <ole...@gmail.com>
Subject Re: [BEP-0003] Database upgrade to multi-product (Was: Re: [Apache Bloodhound] #406: Database upgrade to multiproduct)
Date Wed, 27 Feb 2013 23:32:37 GMT
On 2/27/13, Branko Čibej <brane@wandisco.com> wrote:
> On 27.02.2013 13:01, Olemis Lang wrote:
>> On 2/27/13, Jure Zitnik <jure@digiverse.si> wrote:
>>> On 2/22/13 4:34 PM, Olemis Lang wrote:
>>>> On 2/22/13, Branko Čibej <brane@wandisco.com> wrote:
>>>> [...]
>>>>> P.S.: By the way, do we test upgrades from Trac to BH? If not, why
>>>>> not?
>>>>> :)
>>>>>
>>>> We should .
>>> +1
>>>
>>> It'd be really helpful if we could get hold of a real trac database to
>>> perform tests on. Anyone got access to a database snapshot that we could
>>> use for testing?
>>>
>> Ideally I'd advocate for writing unit and/or functional tests for MP
>> upgrades .
>
> Yes, but you'll never invent tests that reproduce real-world cases
> without looking at real-world cases in the first place.
>

That's what I'd call functional tests . Trac test suite includes some
of them in which a whole environment is created once then shared among
TCs in a test fixture and invoke the whole Trac machinery using twill
to trigger web processing in-process . They'd be close to what u'd get
with manual testing ... with the added benefit of automation e.g.
track regressions . They'd be a sort of «robot» using Bloodhound in
well-known , predefined manner and checking for expected behavior
based on system output.

Having real env data at the beginning is addressed by test fixtures .

BTW , this kind of automation is not an urgent matter , so think of my
comments to be a suggestion to adopt in the long-run

PS: Testing approaches will never be perfect ... but may be quite
similar to reality

-- 
Regards,

Olemis.

Mime
View raw message