[tahoe-dev] how to write unit tests for multiple introducers

[Zooko O'Whielacronx]

Folks:

Faruq is working on #68 -- decentralized introduction -- for GSoC. He
has written patches which allow a client to subscribe to more than one
introducer, but is having trouble understanding how to write unit
tests of such a thing.

(It is pretty normal for people not to understand how to write unit
tests of things like this: networky and user interfacey things where
it seems at first glance that you need an entire running system to
test.)

I'm about to take off for a long weekend of camping (in fact, I'm
halfway up the mountain!), so here are just some quick notes about how
to write such unit tests.

See test_introducer.py

class SystemTest

That is a test that sets up a full system with an introducer and some
servers and a client, and tests that the client learns about the
servers in various conditions.

A good test would be to add a new method named "test_two_introducers"
to that class which sets up two introducers instead of just one. You
might start by copying one of the existing "test_" methods, renaming
it to "test_two_introducers" and then editing it.

However, another even more specific test you could also write would be
to instantiate an instance of src/allmydata/client.py's Client class
(which is the class that your patch touches), after using the
mock.patch() function from the mock package to patch the
allmydata.introducer.client.IntroducerClient class and replace it with
a mock object. Then when you instantiate the instance of Client, it
will execute its own init_introducer_client() method, which will
execute the allmydata.introducer.client.IntroducerClient class (which
has actually been replaced by a mock). Then you can test that the
Client instance has the right number of them or executed the right
methods on them or whatever.

Hm, actually walking through that exercise in that paragraph made me
think that your patch could be made more testable if instead of
changing src/allmydata/client.py's Client to have multiple
IntroducerClient objects, it instead changed the IntroducerClient
object to track multiple introducers. Then you could test it by
instantiating an instance of IntroducerClient and asserting that it
correctly uses multiple servers.

If you're going to rewrite your patch to use that latter strategy
(which seems like a good idea at first glance), then you should
probably *first* write a unit test of the new desired behavior of
IntroducerClient.

Okay, chat with you Monday!

Regards,

zooko