Open Stack

On Thu, Sep 15, 2011 at 12:24 PM, Pitucha, Stanislaw Izaak
<stanislaw.pitucha at hp.com> wrote:
> Hi all,
> I've got some questions about testing the bits affecting the database. Currently some places use mox, some use db_fake / stubs - this unfortunately fails when I try to add another test:
>
> In VlanManager.setup_compute_network(), there's a call to db.network_get_by_instance. I needed to test some part of it that required specific mocking, so I followed what happens in other places of that file - changed db to self.db and used mox.
>
> This however made the xenapi tests fail because they rely on db_fake in test_spawn_vlanmanager (it also calls setup_compute_network()).
>
> So the way I see it now - my options are:
> - rewrite xenapi tests to use mox (lots of work, really don't want to go there)
> - mix mox and db_fake in a single test in test_compute (ugly / don't want to figure out the dependencies there in the future)
> ...
> are there any other solution?
>
> Is there any blessed way to do this in the future? Is it better to keep to db_fake or mox?

Hi Stanislaw!

IMHO, the "best" way to do things is the way in which the *least*
amount of code and *fewest* number of components is stubbed or mocked.
In your particular case, are you testing the interaction of the
database or are you testing the interaction of nova-compute with the
Xen API? If the former, I'd suggest using mox and stubbing out/faking
as little as possible around the database. If it's the latter, I'd
recommend using a fake datastore and testing the true code paths in
Xen API as much as possible.

Hope this help!
-jay