[tahoe-dev] [tahoe-lafs] #68: implement distributed introduction, remove Introducer as a single point of failure
tahoe-lafs
trac at tahoe-lafs.org
Mon Jun 21 18:11:30 PDT 2010
#68: implement distributed introduction, remove Introducer as a single point of
failure
------------------------------+---------------------------------------------
Reporter: lvo | Owner: nobody
Type: enhancement | Status: new
Priority: major | Milestone: eventually
Component: code-network | Version: 0.2.0
Resolution: | Keywords: scalability availability introduction gsoc
Launchpad Bug: |
------------------------------+---------------------------------------------
Comment (by zooko):
Nice work! Next, please write a unit test of these patches. One unit test
should verify that the client learns about a server when that server is
announced to one introducer and also when that server is announced to the
other introducer. The unit test should use a "mock !IntroducerClient
class" to test that code that your patch changed in
[source:src/allmydata/client.py at 4193#L173]. The idea is that the code in
[source:src/allmydata/client.py] thinks that it is instantiating an
instance of [source:src/allmydata/introducer/client.py at 3931#L13
IntroducerClient], but actually the test code has set it up so that when
the code under test instantiates {{{IntroducerClient()}}} then instead it
gets an instance of the mock introducer client.
You can accomplish this using the Python mock library's {{{mock.patch}}}
decorator. You can copy the way we use {{{mock.patch}}} in other places in
our tests if you like to learn by code copying (I like to learn that way).
http://www.voidspace.org.uk/python/mock/
--
Ticket URL: <http://tahoe-lafs.org/trac/tahoe-lafs/ticket/68#comment:26>
tahoe-lafs <http://tahoe-lafs.org>
secure decentralized file storage grid
More information about the tahoe-dev
mailing list