openstack team mailing list archive

[Soren Hansen <soren@xxxxxxxxxxx>]

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