[Openstack] [nova-testing] Efforts for Essex
Soren Hansen
soren at linux2go.dk
Wed Nov 23 20:56:43 UTC 2011
2011/11/23 Sandy Walsh <sandy.walsh at rackspace.com>:
> Thanks Soren, I see what you're doing now and it makes perfect sense.
> It'll be a nice helper class.
Cool.
> My only snipe would be that mox is generic to any library and this
> fake only gives the benefit to db operations. We have to remember
> "It's a db operation, so I have to do this. It's another method call
> so I need to do that"
I think if it more like "for db, I don't need to concern myself with
test doubles. There's still a bunch of other stuff where that's not
true, but for db, it Just Works[tm]."
> How much effort would it be to make it into a better/more generic mox library?
I don't see how that would even be possible? I'm writing a complete db
driver, backed by Python dicts rather than sqlalchemy+sqlite. I can't
imagine how you'd build something that generally can expose an API and
behaviour identical to an arbitrary module, which seems to be what
you're suggesting.
Ok, that's not entirely true. I can imagine injecting a proxy in front
of the real DB driver, record its behaviour, and on subsequent test
runs, I'd return canned responses, but I really wouldn't recommend
something like that. It's great of getting some insight into how a
particular module is used. You can use that information when writing
stubs, mocks, fakes, whatever based on it, but I wouldn't rely on being
able to just replay its traffic and have everything work.
Am I completely misunderstanding you?
--
Soren Hansen | http://linux2go.dk/
Ubuntu Developer | http://www.ubuntu.com/
OpenStack Developer | http://www.openstack.org/
More information about the Openstack
mailing list