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