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 <ztur...@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@cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev _______________________________________________ lldb-dev mailing list lldb-dev@cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
