[Engine-devel] Any way to break the dao_unit_tests up?

Yair Zaslavsky yzaslavs at redhat.com
Tue Aug 21 09:01:53 UTC 2012



On 08/21/2012 11:59 AM, Allon Mureinik wrote:
>
>
> ----- Original Message -----
>> From: "Mike Kolesnik" <mkolesni at redhat.com>
>> To: "Shireesh Anjal" <sanjal at redhat.com>
>> Cc: engine-devel at ovirt.org, "infra" <infra at ovirt.org>
>> Sent: Tuesday, August 21, 2012 9:43:23 AM
>> Subject: Re: [Engine-devel] Any way to break the dao_unit_tests up?
>>
>> ----- Original Message -----
>>> On Monday 20 August 2012 11:16 AM, Mike Kolesnik wrote:
>>>> ----- Original Message -----
>>>>> The DAO unit tests take twice as long as the rest of the test to
>>>>> run
>>>>> is
>>>>> there any way to break them up into two pieces?
>>>>>
>>>> It will not be easy..
>>>>
>>>> The way the tests are built today is with DB-unit.
>>>> DB-unit allows to have an XML file with predefined data (called
>>>> fixtures) which is used to recreate the DB data each time a
>>>> test-class is run.
>>>>
>>>> This is all fine, except that in our tests there are (at least) 2
>>>> issues:
>>>>    1. The same fixtures.xml file is used in all DAO tests.
>>>>    2. Some DAOs require fixtures for several tables.
>>>>
>>>> Now, we could fix issue #1 by splitting the fixtures file into
>>>> smaller files, each relating to only one table, which would allow
>>>> us to run these tests in parallel on the same DB.
>>>> Issue #2 would require to figure out which tests require several
>>>> fixtures, and have them run isolated from the other tests which
>>>> require only a single table.
>>>>
>>>> A simpler solution could be to have the tests run each on it's
>>>> own
>>>> db schema (or it's own db) which eliminates the dependencies and
>>>> allows to run all in parallel, but is a bit more complicated to
>>>> maintain (we would need some script that generates these
>>>> schemas/dbs for tests automatically) and keeping multiple schemas
>>>> up to date would also require CPU time.
>>>>
>>>> This is speaking in terms of the tests themselves, without
>>>> considering the build process itself.
>>>
>>> There are two issues here:
>>>
>>> 1) DB connection is created during initialization of every test
>>> case,
>>> and destroyed at the end of each test case execution
>>> 2) The fixtures data is inserted during initialization of every
>>> test
>>> case
>>>
>>> I think both of these can be resolved by
>>>    - creating the test data only during initialization of the first
>>>    test
>>> case, which will include creating the connection (with auto-commit
>>> =
>>> false), inserting fixtures data and committing it
>>>    - rolling back any changes done to the database during test case
>>> execution in the tearDown method
>>>
>>> I just tried this in two phases. Using the same connection across
>>> all
>>> test cases brought down the dao unit tests run time from 4:42.683s
>>> to
>>> 1:07.628s, and inserting the fixtures data only once further
>>> brought
>>> it
>>> down to just 22.295s ! (on my local development machine)
>>>
>>> I've just sent a patch with these changes:
>>> http://gerrit.ovirt.org/7336
>>
>> Patch merged,
>>
>> Thanks Shireesh for the contribution, now the DAO tests are super
>> fast!
> 20-something seconds to run DAO tests?
> awesome!
> Kudos, Shireesh!

+100 on this, good work!

>>
>>>
>>>>
>>>>> --
>>>>> Thanks
>>>>> Robert Middleswarth
>>>>> @rmiddle (twitter/IRC)
>>>>>
>>>>> _______________________________________________
>>>>> Engine-devel mailing list
>>>>> Engine-devel at ovirt.org
>>>>> http://lists.ovirt.org/mailman/listinfo/engine-devel
>>>>>
>>>> _______________________________________________
>>>> Engine-devel mailing list
>>>> Engine-devel at ovirt.org
>>>> http://lists.ovirt.org/mailman/listinfo/engine-devel
>>>
>>>
>> _______________________________________________
>> Engine-devel mailing list
>> Engine-devel at ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/engine-devel
>>
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
>



More information about the Devel mailing list