[tahoe-dev] New test runs

[Zooko O'Whielacronx]

Dear Faruq:

Yes, I think you're making progress. Please try this:

On Tue, Jul 6, 2010 at 4:23 PM, M O Faruque Sarker <writefaruq at gmail.com> wrote:
> Initial fresh test: http://pastebin.com/yFZWdH1Y
>
> After just self.introducer_furl unlinked: http://pastebin.com/7qxhkA2N

Okay, after self.introducer_furl is unlinked then there is only one
test that fails: allmydata.test.test_system.SystemTest.test_filesystem

Looking at that particular test:

http://tahoe-lafs.org/trac/tahoe-lafs/browser/trunk/src/allmydata/test/test_system.py?rev=4479#L702

I see that it is really an overarching test which sets up an entire
running grid of introducer, clients, and servers, and then exercises
lots of major functionality: uploads, downloads, WUI, CLI, checker,
etc..

Once your patch is more complete we should probably update
test_system.py to make sure that it tests the entire running system in
such a way that the entire running system has to have your new
feature. (For example, perhaps start with one introducer, then do some
operations, then add another introducer, then take down the first
introducer, then add more storage servers, then do more operations, or
something like that.)

But for now, we want to make as small and focussed of a test as
possible to make sure that all the code is correctly handling the
presence of the .introducer_furls attribute and the absence of the old
.introducer_furl attribute.

So, now leave the test_system.py test red for now, in your local
sandbox, and write up a test that tests just the code which you *know*
is currently incorrect in that sandbox since that code is trying to
access a .introducer_furl attribute that doesn't exist. I believe you
said that the only such code (outside of tests) is web/root.py, and
you were working on a test which would execute web/root.py's
data_introducer_furl() method. On IRC I suggested passing a mock
object for its arguments, like:

mockctx = mock.Mock()
mockdata = mock.Mock()
data_introducer_furl(mockctx, mockdata)

The overall strategy here is to write a test for each change that you
make. The fact that you can remove the "introducer_furl" attribute
from src/allmydata/client.py Client without triggering redness in a
test which is specifically about the WUI's display of the introducer
furls means that we need a new test which is specifically about that.

As soon as you have such a test then you can proceed with the rest of
your patch while knowing that anything else you do won't silently
cause the display of the introducer furls in the WUI to break.

Now the next thing you should do, once you have a test of
data_introducer_furl(), is, I think, to run the test you already
wrote:

http://tahoe-lafs.org/trac/tahoe-lafs/attachment/ticket/68/test_multi_introducers.py

And see that the new test comes up red, and then apply a subset of your patch:

http://tahoe-lafs.org/trac/tahoe-lafs/attachment/ticket/68/client(can-subscribe-to-multi-introducer-backward-compat).dpatch

Which is just enough of your patch to make that test turn green.
However, do *not* apply any parts of your patch which are not
necessary to make that test turn green.

Then the *next* step is to write a new test which tests how the code
uses the old "introducer.furl" entry in the tahoe.cfg file. What is
the intended behavior in that case? Should it include both the old
introducer.furl from the tahoe.cfg file as well as the new set of
introducer furls from the "introducers" config file into one set? Or
should it ignore the old introducer.furl from the tahoe.cfg file if
there is a new-style "introducers" config file present? (I would lean
toward the latter.)

In any case, once you have a unit test that is red and that will go
green only if the code behaves correctly with regard to handling both
old-style and new-style introducer furls in config files, then you
apply the parts of your patch which are necessary to make that test go
green.

See how this works? The rule is you're not allowed to write any code
unless you have a red unit test, and once you have a red unit test
then you immediately go and write the code that will make it green,
but no other code.

Regards,

Zooko