dotest is also a potentially fallible layer on top of the SB Api call, but one that involves *more* behind-the-scenes code between the test and code being tested. <br><br>An lldb-test test would consist, in its entirety, of about 10 lines of text.  I don’t see how it’s possible to beat that from a simplicity standpoint (and you get the added bonus that the thing running the test is known to not be flaky)<br><div class="gmail_quote"><div dir="ltr">On Mon, Jan 29, 2018 at 4:33 PM Jim Ingham via Phabricator <<a href="mailto:reviews@reviews.llvm.org">reviews@reviews.llvm.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">jingham added a comment.<br>
<br>
Yes.  We do need to have symbols to do symbol completion, which does require a binary, but you don't need to run it.  Most of the other tests in there (e.g. simple command completion) should be able to work without even a binary.  It seems weird to add a potentially fallible lldb-test layer on top of SBCommandInterpreter.HandleCompletion just so you can send text input through lldb-test rather than directly sending text input to SBCommandInterpreter.HandleCommand.<br>
<br>
<br>
<a href="https://reviews.llvm.org/D42656" rel="noreferrer" target="_blank">https://reviews.llvm.org/D42656</a><br>
<br>
<br>
<br>
</blockquote></div>