openstack team mailing list archive

[Soren Hansen <soren@xxxxxxxxxxx>]

2011/11/22 Sandy Walsh <sandy.walsh@xxxxxxxxxxxxx>:
> I'm not a big fan of faking a database, not only for the reasons outlined already, but because it makes the tests harder to understand.

Can you give me an example? I find the opposite to be true, so I'd
love to see counterexamples. Most of the time, the data store is not
relevant for the tests. I just need to stick an instance into the db,
do some stuff, and verify that I get the correct (direct and indirect)
output. I don't see how having a mocked db.instance_get is any more
readable than a db.instance_create() (or a parameterised
create_instance utility method for testing purposes or whatever).

> I much prefer to mock the db call on a per-unit-test basis so you can see everything you need in a single file. Yes, this could mean some duplication across test suites. But that is better than changes to the fake busting some other test that has different assumptions.

That's why I'm adding tests for the fake. To make sure that the fake
and the real db drivers act the same.

> Are we testing the code or are we testing the fake?

The code. We have *other* tests for the fake.

> (real) Unit tests are our documentation and having to jump around to find out how the plumbing works doesn't make for good documentation.

I agree. That's exactly why I *don't* want mocks (for this) in the unit tests.

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