Directly WRT testing. I’m not against ALSO adding gtests when you add some functionality. But when your change is actually adding behaviors to lldb, one of the things you need to ask yourself is if this is functionality that extension developers for lldb will benefit from. If it is, then adding affordances in the SB API should be considered an essential part of a complete implementation of the feature. And I assert from experience that writing tests for that feature at the SB API layer is a really good way to ensure that the API’s you add make sense and actually get at the things you intended to make available.
So for anything like the change we are directly discussing, you should first think about how to make an SB affordance for it. Then test that to make sure it makes sense. Then if you feel like you also want to add gtests because there was something you couldn’t easily get through the SB API’s, please do so! Jim > On Sep 20, 2017, at 10:41 AM, Zachary Turner <ztur...@google.com> wrote: > > > > On Wed, Sep 20, 2017 at 10:33 AM Jim Ingham <jing...@apple.com > <mailto:jing...@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.
_______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
