<div dir="ltr">FileCheck the ansi escape codes seems like one possibility.<div><br></div><div>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.</div><div><br></div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Jan 31, 2019 at 10:42 AM Pavel Labath <<a href="mailto:pavel@labath.sk">pavel@labath.sk</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 31/01/2019 19:26, Zachary Turner wrote:<br>
> Was the test failing specifically in the keyboard handler for up arrow, <br>
> or was it failing in the command history searching code?  Because if <br>
> it's the latter, then we could have a command which searches the command <br>
> history.<br>
> <br>
<br>
The patch is r351313, if you want to look at it in detail. But, I don't <br>
think this one example matters too much, since we will always have some <br>
code which deals with the interactivity of the terminal. That will need <br>
to be tested somehow.<br>
<br>
Another example: we have a fairly complex piece of code that makes sure <br>
our (lldb) prompt comes out in color. How do we write a test for that?<br>
</blockquote></div>