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
