> On Sep 19, 2017, at 6:57 PM, Zachary Turner via lldb-commits
> <lldb-commits@lists.llvm.org> wrote:
>
>
>
> After some additional thought, I stilled think testing below the sb api layer
> is more appropriate.
> While Xcode might be going through the SB api, users of upstream lldb
> (which is what we supposed to be testing upstream) are not.
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).
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.
>
> In order to achieve maximum test coverage and minimal flakiness, there should
> be 2 tests:
>
> the first test is for core functionality and tests that if you pass call tge
> interrupt function, it gets interrupted and the output is as expected.
>
> The second test test checks that if you call the Python api, it calls the
> function that has been tested by step 1.
>
> If you want a third function that tests both, you can certainly do that, but
> this way the creation of a test is not blocked on the addition of a Python
> api.
> _______________________________________________
> lldb-commits mailing list
> lldb-commits@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
_______________________________________________
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
