[lldb-dev] [RFC]The future of pexpect

[Pavel Labath via lldb-dev]

On 31/01/2019 19:51, Zachary Turner wrote:
 > FileCheck the ansi escape codes seems like one possibility.
 >
 > In general I think you don't actually need to test true interactivity,
 > because the odds of there being a problem in the 2-3 lines of code that
 > convert the keyboard press to something else in LLDB are very unlikely
 > to be problematic, and the rest can be mocked.


On 31/01/2019 20:02, Jim Ingham wrote:
> All the traffic back and forth with the terminal happens in the IOHandlerEditLine.  We should be able to get our hands on the Debuggers IOHandler and feed characters directly to it, and read the results.  So we should be able to write this kind of test by driving the debugger to whatever state you need with SB API and then just run one command and get the output string directly from the IOHandler.  We should be able to then scan that output for color codes.  I don't think we need an external process inspection tool to do this sort of thing.
> 


Libedit expect to work with a real terminal, so to test the code that 
interacts with libedit (and there's more than 3 lines of that), you'll 
need something that can create a pty, and read and write characters to 
it, regardless of whether you drive the test through FileCheck or SB API.

"creating a pty, and reading and writing to it" is pretty much the 
definition of pexpect.

I am not saying either of this approaches can't be made to work, but I 
am not sure who is going to do it. I fear that we are shooting ourselves 
in the foot banning pexpect and then pushing patches without tests 
because "it's hard".

Just for fun, I tried to write a test to check the coloring of the 
prompt via pexpect. It was _literally_ three lines long:

def test_colored_prompt_comes_out_right(self):
     child = pexpect.spawn(lldbtest_config.lldbExec)
     child.expect_exact("(lldb) \x1b[1G\x1b[2m(lldb) \x1b[22m\x1b[8G")


BTW: I am not proposing we spend heroic efforts trying to port pexpect 
2.4 to python3. But I would consider using a newer version of pexpect to 
write tests ***where it makes sense to do so***. At least until someone 
comes up with a better (and not vapourware) alternative...

pl