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...

lldb-dev mailing list

Reply via email to