[Lldb-commits] [PATCH] D37923: Implement interactive command interruption

[Zachary Turner via lldb-commits]

On Wed, Sep 20, 2017 at 10:33 AM Jim Ingham <jingham at apple.com> wrote:

> One of the fundamental goals of lldb is that it be an extensible
> debugger.  The extension mechanism for command line lldb all runs through
> the SB API through either Python or C++ (though most folks choose to use
> Python).  We know first hand that many people take advantage this mechanism
> to add custom commands specific to their workflows.  Again, look at the xnu
> macros for an example if you remain unconvinced of this.  Facebook also
> made a nice set of extension commands for introspecting UI elements when
> debugging iOS apps.  And every WWDC folks come with questions about how to
> implement some command or other.  If this doesn’t convince you also check
> out the effort the gdb folks have made and continue to make to support the
> Python extensions to what is purely a command-line debugger.
>
> Not to mention that most of the powerful things you can do with breakpoint
> callbacks are available through the SB API's, and most sophisticated data
> formatters are written in Python.  And again based on questions and bug
> reports we get there are many people using this facility.
>
> I’ve said this many times before, but the notion that the SB API’s are not
> a crucial part of the command-line lldb experience shows a fundamental
> misperception of the design of lldb.
>
> Jim
>

I don't disagree with this, only with the notion that every test is best
written by involving the extensibility layer in the test.

A fundamental and universal principle of good test design is writing tests
that test the minimal amount of code necessary to verify a piece of
functionality.  You don't *need* an extensibility layer to check if you can
stop at a breakpoint.

The fact that the extensibility mechanism provides a way of stopping at
breakpoints just means you should *also* have a test that says "did the
extensibility mechanism properly tell the debugger to stop at a
breakpoint?".

And, of course you can (and should) also have full integration tests that
check the extensibility mechanism end-to-end.

But they just should not be the first and only line of defense.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-commits/attachments/20170920/0139fb3f/attachment.html>