[lldb-dev] pexpect again

[jingham at apple.com]

I know that over time we have broken the lldb driver argument processing, and not having tests we didn't find out till some time later.  So having tests for the driver (and indeed more than we have now because I am pretty sure our coverage in that area is pretty light) is a good and necessary thing.  The test you quote is specifically testing that the driver parses this argument correctly.  It should definitely stay.

I'm curious as to why is there no pexpect for Windows?  That seems pretty odd to me.  Expect was ported to Windows quite some time ago, so all the things pexpect tries to do must be possible...

Jim


> On Jan 20, 2015, at 1:28 PM, Zachary Turner <zturner at google.com> wrote:
> 
> A long time ago I noted that some of the tests are using pexpect.  pexpect doesn't exist on Windows, so we basically don't have test coverage for any of this stuff on Windows.  At the time I just left it alone because there were bigger fish to fry, but now that we have the test suite running, these are surfacing as failing tests.  
> 
> I'm going to submit a patch soon to XFAIL every test that uses pexpect on Windows, but I would like to propose longer term eliminating pexpect tests entirely.  I didn't study every single test that uses pexpect closely, but it seems to me that generally pexpect is used to launch lldb as a separate process, then send text commands to it, then check that the prompt looks correct.  
> 
> In most cases, there's no reason that we specifically need to do this out-of-process, and the actual functionality being tested would work just as well through an in-process public API test.  For example, in TestSingleQuoteInFilename.py, we run "./lldb --lldb-noinit "path with '09/a.out"
> 
> What I think we should really be testing here is whether the "target create" command works with an argument that has a single quote in it.  Anything that's broken between typing a command on the shell and formulating a "target create" command is going to something with shell expansion.
> 
> So I think this test could be re-written to simply run a target create in-process using the extension module, and sanity check the resulting debugger state.
> 
> Similar logic applies for other tests that use pexpect.
> 
> Is anyone opposed to an effort to remove pexpect in this fashion?
> _______________________________________________
> lldb-dev mailing list
> lldb-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev