[Maas-devel] Tests and cluster RPC commands

[Gavin Panella]

On 9 September 2014 11:14, Raphaël Badin <raphael.badin at canonical.com> wrote:
> More and more we're using cluster RPC commands from the region… which
> means that the region and the cluster code are more and more dependant
> on one another. In the test code, the division between cluster and
> region is still very much there because we have to stub things out
> manually every time we call a cluster RPC method. This mismatch is
> starting to be more and more painful because each change involving
> adding a call to a cluster RPC method can possibly force you to update
> a lot of existing tests.
>
> For example, this is the kind of setup we have to do to get the
> cluster to respond to 'CreateHostMaps' and 'PowerOn'.
>
> def prepare_rpc_to_cluster(self, nodegroup):
>     self.useFixture(RegionEventLoopFixture("rpc"))
>     self.useFixture(RunningEventLoopFixture())
>     rpc_fixture = self.useFixture(MockLiveRegionToClusterRPCFixture())
>     protocol = rpc_fixture.makeCluster(
>          nodegroup, cluster.CreateHostMaps, cluster.PowerOn)
>     return protocol

A lot of the above could be consolidated:

    class R2CFixture(fixtures.Fixture):

        def setUp(self):
            super(R2CFixture, self).setUp()
            self.useFixture(RegionEventLoopFixture("rpc"))
            self.useFixture(RunningEventLoopFixture())
            self.rpc = self.useFixture(
                MockLiveRegionToClusterRPCFixture())


    class MyTest(...):

        def test_things(self):
            rpc_fixture = self.useFixture(R2CFixture()).rpc
            protocol = rpc_fixture.makeCluster(
                nodegroup, cluster.CreateHostMaps, cluster.PowerOn)

>
> I wondering if we couldn't have something more systematic and have
> this done, for all the available cluster RPC methods, in the base test
> class (and for every cluster created in the tests). Of course you'll
> have to configure mock objects if you're expecting a particular
> response from one of the RPC methods. But if all you need is the code
> not to blow up because a cluster RPC method has been called as a
> side-effect of what you're actually testing, this will be taken care
> of.

If we get to the point where we're stubbing out more than 2 or 3 RPC
calls in a test then we're not writing a unit test any more. The desire
for a does-all-the-things mock cluster might be a manifestation of
writing overly broad tests, or of not writing small enough units of
testable code. Equally, having a does-all-the-things mock makes it
easier to write overly broad tests and overly large units of code.

Fwiw, I think signals in model code can contribute to this: tests always
have to deal with side-effects from signals, which now might include
RPC. I liked the way that we dealt with needing side-effects as a result
of model changes in Launchpad: enforce use of a mutator method and
forbid use of the model attribute from view/controller code. We could
test the mutator, its use was explicit, but we could bypass it when
setting up tests.