Open Stack

I suppose there is a matter of preference here. I prefer to look in the setup() and teardown() methods of my test suite to find out how everything hangs together. Otherwise I have to check nova.TestCase when things break. The closer my test can stay to my expectations from unittest.TestCase the happier I am. 

I can't comment on your fake db implementation, but my fear is this scenario:

Test1 assumes db.create_foo() will return 123 and Test2 assumes it will return "abc". How do they both comfortably co-exist? And whatever the mechanism, why is it better than just stubs.Set("db.create_foo", _my_create_foo)? 

It's local and it makes sense in the context of that file.

-S

________________________________________
From: Soren Hansen [soren at linux2go.dk]

2011/11/22 Sandy Walsh <sandy.walsh at rackspace.com>:
> I'm not a big fan of faking a database, not only for the reasons outlined already, but because it makes the tests harder to understand.

Can you give me an example? I find the opposite to be true, so I'd
love to see counterexamples. Most of the time, the data store is not
relevant for the tests. I just need to stick an instance into the db,
do some stuff, and verify that I get the correct (direct and indirect)
output. I don't see how having a mocked db.instance_get is any more
readable than a db.instance_create() (or a parameterised
create_instance utility method for testing purposes or whatever).