<div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">On Wed, Sep 20, 2017 at 10:33 AM Jim Ingham <<a href="mailto:jingham@apple.com">jingham@apple.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word">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.<div><br></div><div>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.<br><div><br></div><div>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.</div></div></div><div style="word-wrap:break-word"><div><div><br></div><div>Jim</div></div></div></blockquote><div><br></div><div>I don't disagree with this, only with the notion that every test is best written by involving the extensibility layer in the test.</div><div><br></div><div>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.</div><div><br></div><div>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?".</div><div><br></div><div>And, of course you can (and should) also have full integration tests that check the extensibility mechanism end-to-end.</div><div><br></div><div>But they just should not be the first and only line of defense.</div></div></div>