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 [so...@linux2go.dk]
2011/11/22 Sandy Walsh <sandy.wa...@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).
_______________________________________________
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help : https://help.launchpad.net/ListHelp
