Open Stack

On 12/10/2012 01:04 PM, Sean Dague wrote:
> On 12/10/2012 11:58 AM, Adam Young wrote:
>> On 12/10/2012 11:36 AM, Kevin L. Mitchell wrote:
>>> On Mon, 2012-12-10 at 09:59 +1000, Matthew Sherborne wrote:
>>>> Why don't we create and destroy a test sqlite in memory database for
>>>> the tests instead of stubbing out the DB calls ?
>>> Stubbing out the DB calls makes perfect sense for the unit tests, which
>>> honestly should be (but isn't) the bulk of our test suite. Using an
>>> in-memory database is exactly what should be happening for the function
>>> tests, and Monty's comment indicates that it is…
>>>
>> A quibble:  We do the sqlite in memory thing for most unit tests in
>> Keystone.  I see it as our Mock DB implementation, and it provides a
>> better unit test than reimplementing a halfway set of sql mock objects.
>
> Given the complexity of the nova db, and the number of migrations that 
> build up (50+ in Essex -> Grizzly) there are performance implications 
> to keep doing that over and over again for all the unit tests, 
> especially the ones that are separated enough from the database that 
> their code should be tested in isolation.
Fair enough, and it doesn't have to be all-or-nothing.  We actually now 
have some unit tests for the Database migrations themselves.

It might make sense, though, to capture the end state of the database 
migrations in a sql dump to be used for the unit tests.



>
>     -Sean
>