openstack team mailing list archive

[Soren Hansen <soren@xxxxxxxxxxx>]

2011/11/22 Sandy Walsh <sandy.walsh@xxxxxxxxxxxxx>:
> 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/