<div dir="ltr"><div class="gmail_quote"><div dir="ltr">On Wed, Sep 14, 2016 at 11:43 PM Jason Molenda <<a href="mailto:jmolenda@apple.com">jmolenda@apple.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">If we want to add a testsuite runner which takes a source file, a place to put a breakpoint, the name of a variable to examine, and it runs through those in SB API, I'm all in favor.  I don't know if that's going to add a lot of test coverage to lldb, but I have no problem with such a thing.<br class="gmail_msg">
<br class="gmail_msg">
My goal isn't to make test case writing hard.  My goal is to make the testsuite a benefit to the project, instead of a boat anchor.<br class="gmail_msg">
<br class="gmail_msg">
My non-goal is what testsuite harness is used to run the SB API tests - whether it's lit or whatever, I don't care.<br class="gmail_msg"></blockquote><div><br></div><div>It sounds like your goal is also "tests have to use the SB API and no other API", which if so I think that's counterproductive.   More productive, IMO, would be being open to any alternative that addresses the concerns you have with command-line tests.  There are more than 2 ways to skin a cat, so to speak.</div><div><br></div><div>Aside from that, it sounds like we have the same goal -- make the test suite a benefit to the project rather than a boat anchor.  I guess we differ on what constitutes a benefit and a boat anchor.  TBH I think the current test suite is a boat anchor due to its numerous stability issues and the barrier to entry for writing new tests.  lit wins by leaps and bounds in both of these areas.  If there were something else that were even better, then I'd be all for using it (although then we'd have to question why LLVM doesn't also use it).  But the fact is -- as a test infrastructure, lit is better.</div><div><br></div><div><br><br><div class="gmail_quote"><div dir="ltr">On Wed, Sep 14, 2016 at 11:19 PM Jason Molenda <<a href="mailto:jmolenda@apple.com">jmolenda@apple.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">It's great to make writing tests easier.  We'd all love to have more tests.<br class="gmail_msg"><br class="gmail_msg">If "writing tests easier" is "command line output scraping", that's only hurting the project in the long term.  I'm telling you this from years of experience on a project where we did exactly this.  It's great to have examples where we're testing that "p 5" prints 5.  That's awesome and I'm sure it won't break.  But that's not more than a tiny fraction of what you need to test in a debugger.</blockquote><div><br></div><div>At least 2 different brainstorm ideas have been proposed that would make lit tests not rely on "command line output scraping".  A command line is just a particular form of an API.  The SB API is another form of an API.  There are infinite numbers of ways to design an API, these aren't the only 2 APIs in the world.  One could easily imagine an "API" that was itself a single LLDB command and which you could pass some kind of argument to it that resolved to an SB API call.  Sean gave an example earlier.</div><div><br></div><div><div class="gmail_msg" style="color:rgb(33,33,33);font-family:"helvetica neue",helvetica,arial,sans-serif;font-size:13px">(lldb) script lldb.frame.FindVariable("argc").GetValue()</div><div class="gmail_msg" style="color:rgb(33,33,33);font-family:"helvetica neue",helvetica,arial,sans-serif;font-size:13px">'1'</div><div class="gmail_msg" style="color:rgb(33,33,33);font-family:"helvetica neue",helvetica,arial,sans-serif;font-size:13px">(lldb) script lldb.process.GetNumThreads()</div><div class="gmail_msg" style="color:rgb(33,33,33);font-family:"helvetica neue",helvetica,arial,sans-serif;font-size:13px">1</div><div class="gmail_msg" style="color:rgb(33,33,33);font-family:"helvetica neue",helvetica,arial,sans-serif;font-size:13px">(lldb) script lldb.process.GetThreadAtIndex(0).GetThreadID()</div><div class="gmail_msg" style="color:rgb(33,33,33);font-family:"helvetica neue",helvetica,arial,sans-serif;font-size:13px">3514809</div></div><div class="gmail_msg" style="color:rgb(33,33,33);font-family:"helvetica neue",helvetica,arial,sans-serif;font-size:13px"><br></div><div class="gmail_msg" style="color:rgb(33,33,33);font-family:"helvetica neue",helvetica,arial,sans-serif;font-size:13px">Assuming your test ran against this output, is this a "command line scraping" test or an "SB API" test?  Seems to be both, which is why I keep saying that it's unproductive to talk about SB API tests and command line scraping tests as the entire universe of options.</div><div class="gmail_msg" style="color:rgb(33,33,33);font-family:"helvetica neue",helvetica,arial,sans-serif;font-size:13px"><br></div><div class="gmail_msg" style="color:rgb(33,33,33);font-family:"helvetica neue",helvetica,arial,sans-serif;font-size:13px">But even the above is not the only possibility.  You could directly map every single SB API call to an LLDB command-line independent of the normal command line UI.  One-to-one mapping</div><div class="gmail_msg" style="color:rgb(33,33,33);font-family:"helvetica neue",helvetica,arial,sans-serif;font-size:13px"><br></div><div class="gmail_msg" style="color:rgb(33,33,33);font-family:"helvetica neue",helvetica,arial,sans-serif;font-size:13px">(lldb) object lldb.frame.variables["argc"].value</div><div class="gmail_msg" style="color:rgb(33,33,33);font-family:"helvetica neue",helvetica,arial,sans-serif;font-size:13px">'1'</div><div class="gmail_msg" style="color:rgb(33,33,33);font-family:"helvetica neue",helvetica,arial,sans-serif;font-size:13px">(lldb) object lldb.process.threads.count</div><div class="gmail_msg" style="color:rgb(33,33,33);font-family:"helvetica neue",helvetica,arial,sans-serif;font-size:13px">1</div><div class="gmail_msg" style="color:rgb(33,33,33);font-family:"helvetica neue",helvetica,arial,sans-serif;font-size:13px">(lldb) object lldb.process.threads[0].id</div><div class="gmail_msg" style="color:rgb(33,33,33);font-family:"helvetica neue",helvetica,arial,sans-serif;font-size:13px">3514809</div><div class="gmail_msg" style="color:rgb(33,33,33);font-family:"helvetica neue",helvetica,arial,sans-serif;font-size:13px"><br></div><div class="gmail_msg" style="color:rgb(33,33,33);font-family:"helvetica neue",helvetica,arial,sans-serif;font-size:13px">Is this really any different than the script example above?</div><div class="gmail_msg" style="color:rgb(33,33,33);font-family:"helvetica neue",helvetica,arial,sans-serif;font-size:13px"><br></div><div class="gmail_msg" style="color:rgb(33,33,33);font-family:"helvetica neue",helvetica,arial,sans-serif;font-size:13px">So I would request that we stop talking about "command line scraping tests".  Let's focus on the actual issue, which is "tests that are hard to maintain: bad.  Tests that are easy to maintain: good"</div></div></div></div></div>