<div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">On Tue, Sep 19, 2017 at 7:12 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"><br>
<br>
> On Sep 19, 2017, at 6:57 PM, Zachary Turner via lldb-commits <<a href="mailto:lldb-commits@lists.llvm.org" target="_blank">lldb-commits@lists.llvm.org</a>> wrote:<br>
><br>
><br>
><br>
> After some additional thought, I stilled think testing below the sb api layer is more appropriate.<br>
>   While Xcode might be going through the SB api, users of upstream lldb (which is what we supposed to be testing upstream) are not.<br>
<br>
<br>
One thing to keep in mind is that while Xcode is the IDE using lldb that Apple directly supports, there are many other IDEs that are using lldb today.  I don't know for certain that all these are using SB API, but a partial list of additional IDEs in addition to Xcode includes CLion ("A Cross-Platform IDE for C and C+ by JetBrains"), Nuclide (atom based IDE), Android Studio, Visual Code Studio, and Eclipse (I know this one is done via lldb-mi).<br>
<br>
Command line lldb is the interface I personally tend to prefer, but it is not the interface that the vast, vast majority of our users use when debugging with lldb.  SB API is.  The lldb driver is more akin to one front-end among many, and an odd one, given that it doesn't go through the SB API itself.<br></blockquote><div><br></div><div>Definitely, but that's also one reason I think it's so important to split the tests up.  Right now there is almost no coverage of not going through the SB API, and yet that is the interface that we, as the upstream open-source project, provide to users.  And while it may not be the interface that the vast majority of users *currently* use, I think if we compared the number of people using GDB to the number of people using LLDB, it paints a different picture.  Namely, a picture of how many users *could* be using LLDB.  </div><div><br></div><div>I don't want to break any existing users of LLDB obviously, including those that go through the SB API, but at the same time the primary product that comes out of the open-source project is, in fact, a command line debugger, and we should strive to make that experience as good as possible.</div><div><br></div><div>I believe if the tests are split into private tests and public API tests you get the best of both worlds.  I would even go farther to say that the whole is greater than the sum of parts, because it makes it easy to write tests for any new api that comes along, and vastly reduces the barrier to entry to writing new tests, which I still believe is one of the most critical bugs facing the project today.</div></div></div>