Re: [Fab-user] status of "occasional droped lines of output" bug 32

[Steve Steiner (listsin)]

On Aug 7, 2009, at 6:22 PM, Jeff Forcier wrote:

> On Fri, Aug 7, 2009 at 5:31 PM, Steve Steiner
> (listsin)<address@hidden> wrote:
>
> > I tried to write a unit-test for this using a simple local() call  
> > to just
> > cat a file that didn't have a trailing EOL char but couldn't get it  
> > to fail
> > properly.
>
> Well, local() and run()/sudo() are actually very different under the
> hood and share zero code (simple subprocess.Popen usage vs complicated
> network IO loop, respectively), which is why this problem can't
> (unfortunately) be solved by using local().

Right.  This particular problem is in network.py and has to do with  
the way the data is glopped together in the threaded off output  
capturer.  After I read the fabric.operations.local code I figured out  
that they share exactly zero code.

This is going to be tricky to unittest since you need either a "live"  
server or a really smart mock object.

> I'll have to see what I can do; I would like to at least get this one
> problem unit-tested as a way of breaking into the "how *do* we
> mock/stub a network connection" problem.

I tried to follow the chain down through the channel object trying to  
see where to "put the screw" but I'm not familiar enough with this  
code to really see where to insert the mock.  Obviously, it needs to  
be as far out (or is that in?) as possible so that the most actual  
Fabric code gets exercised.

At this point, since you have a server set up for various other fabric  
server functions, maybe just make a really, really restricted user  
that can only execute "ls -l" on one directory solely for purpose of  
testing this specific issue.  We could waste a  _lot_ of time trying  
to create a mock object at the right level and we might find ourselves  
doing it more than once.  The advantage of a live server is that it  
actually exercises the whole chain, not just up to the mocked object.

> Not to mention actually having regression testing -- fixes to this  
> area seem to create other
> bugs pretty consistently.

It does seem to be a 'picky spot' in the code.

S