2011/11/22 Sandy Walsh <sandy.wa...@rackspace.com>: > 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.
Sorry, I don't follow. The unit tests would use the fake db driver by default. No per-test-specific setup necessary. Creating the instance in the fake DB would happen explicitly in the individual tests (by way of either calling db.instance_create directly, or by way of some utility function). > 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)? I'm confused. That's *exactly* what I want to avoid. By everything sharing the same fake db driver, you can never have one mock that returns one style of response, and another mock that returns another style of response. > It's local and it makes sense in the context of that file. But it has to make sense globally. If something you're testing only ever sees an Instance object with a couple of "hardcoded" attributes on it, because that's what its mock gives it, you'll never know if it'll fail if it gets a more complete, real Instance object. -- Soren Hansen | http://linux2go.dk/ Ubuntu Developer | http://www.ubuntu.com/ OpenStack Developer | http://www.openstack.org/ _______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp