openstack team mailing list archive

[Soren Hansen <soren@xxxxxxxxxxx>]

2011/11/22 Mark Washenberger <mark.washenberger@xxxxxxxxxxxxx>:
> I think we all agree that we have a mess with the database stubbing that is going on. And I'm confident that the db fake would make that mess more manageable.

> But the way I see the mess, it comes from having a giant flat db interface and really large testcases.

Those are definitely problems, too. The lack of an alternative DB
driver (be it a fake or a real one) hasn't helped, either :(

> Also, by having such large test cases, the generality & complexity of setUp() as well as its distance from any given test method increase tremendously.

I agree completely.

> All of this makes it harder to understand the impact of any one line in setUp and nearly impossible to tell which parts of setUp are relevant to a given test.

Absolutely. At the moment, it's extremely difficult to tell which
parts of the setUp is actually needed for each individual test.

> But, I have to admit that I'm not backing up the way I think we could make the best improvements with any code at the moment--and Soren is. So I'm not sure I really want to stand in the way.

:) I'm hoping the code and the changes it will bring along will speak
for itself once I'm done with it. I've implemented 138 of 291 db api
methods in my fake driver. I don't know if I'll need all 291 for the
unit tests to pass. I hope so, but I'm not sure at all.

> My only detraction from a big fake is that it in general has to be a pretty faithful implementation of the real interface.

Again, with my fake db driver, I'll submit a test suite for it. A test
suite that we can run against *any* db driver (real, fake, whatever)
to verify that they're all faithful.

-- 
Soren Hansen        | http://linux2go.dk/
Ubuntu Developer    | http://www.ubuntu.com/
OpenStack Developer | http://www.openstack.org/