<div dir="ltr">We’ve had this discussion several times, but at the end of the day nothing has really changed with the larger llvm project having adopted this model and having spent significant effort in moving forward with it.<div><br></div><div>Normally, the reason we don't use this model for LLDB tests is because they require interactivity, and if need be I can find several threads where the response has been, specifically "FileCheck tests aren't a good fit for LLDB because of the interactivity and the nature of the test doesn't lend itself well to textual output comparison".</div><div><br></div><div>So here we have a case where there is no interactivity, and in fact the test lends itself perfect to textual comparison.  With all due respect, given that the previously stated reasons for preferring not to use text-scraping tests don't apply in this case, combined with the fact that there is a strong desire by the larger project to use a standard, cross-project testing infrastructure that is understood by several hundred developers instead of several, I don't see a good reason to not at least attempt this route in cases where it makes sense.</div><div><br></div><div><br></div><div><br><div class="gmail_quote"><div dir="ltr">On Wed, Nov 29, 2017 at 12:07 PM Jim Ingham via Phabricator <<a href="mailto:reviews@reviews.llvm.org" target="_blank">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>
It does look a little weird as a unit test, but to me this is mostly because it would been much simpler to write it as a regular SB API test.<br>
<br>
Anyway, I really don't want the details of the text output of lldb commands to become API.  Our experience with gdb was that over time as you write more and more tests that scrape text output, you end up not being able to change command output because the burden of fixing up all the tests becomes too onerous.  You can use text scraping in the current lldb testsuite.  We discourage that for the reasons above, and try to isolate the tests that do so by having lldbutils interfaces to do the explicit scraping.  But it is just as easy, and quite often much easier, to examine objects directly in the lldb testsuite, so this mechanism encourages virtue, even though it doesn't enforce it.<br>
<br>
OTOH adding a test mechanism that explicitly relies only on command output scraping leads us down the path that ended up being a real PITN for the gdb testsuite.  So for that reason I am not in favor of going this way.<br>
<br>
<br>
<a href="https://reviews.llvm.org/D40616" rel="noreferrer" target="_blank">https://reviews.llvm.org/D40616</a><br>
<br>
<br>
<br>
</blockquote></div></div></div>