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
_______________________________________________
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
