On Thu, Jan 31, 2019 at 11:40 AM Pavel Labath <pa...@labath.sk> wrote:
> 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

I found out that there are tests that effectively require
interactivity. Some of the lldb-mi ones are an example.
A common use-case is that of sending SIGTERM in a loop to make sure
`lldb-mi` doesn't crash and handle the signal correctly.

This functionality is really hard to replicate in lit _as is_.
Any ideas on how we could handle this case?


lldb-dev mailing list

Reply via email to