2011/11/22 Sandy Walsh <sandy.wa...@rackspace.com>:
> 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/

Mailing list: https://launchpad.net/~openstack
Post to     : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Reply via email to