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

[Jim Ingham via lldb-commits]

I write lots of tests.  I don’t really think that the SB API’s are really a barrier to writing tests.  The lldbinline tests are trivial to write and can even be made just as a transcription of an lldb command line session, so the barrier to entry is trivial.  That is surely the easiest way to write tests for behavior that is available at the Command line or SB levels.  The SB tests are not much harder to write.  The fact that we didn’t have easy templates for writing tests for a while made figuring out how to get started hard.  But the sample_tests make it easy to get yourself to a debugger with a loaded target that you can poke at.  I just can’t see how a developer who can write good C++ code could have any difficulty write an SB API test. 

Moreover, for anything that requires complex setup, the python tests are much easier to write than lldb_private API tests because the SB API’s are specifically meant to be a streamlined way to drive the debugger.  So for somebody coming in to make a surgical fix who is not an LLDB expert, making them learn the lldb_private API’s for driving a debug session is even more work that the SB API’s.

The amount of test coverage lldb has at present has much more to do with the very aggressive schedules lldb has been driven by since its inception than any difficulties with writing tests IMHBSEO.  

Jim


> On Sep 20, 2017, at 10:50 AM, Zachary Turner <zturner at google.com> wrote:
> 
> On Wed, Sep 20, 2017 at 10:46 AM Jim Ingham <jingham at apple.com <mailto:jingham at apple.com>> wrote:
> 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.
> 
> I also assert from experience that unfortunately it's also a good way to make sure that the test doesn't get written in the first place :(
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-commits/attachments/20170920/f7453c02/attachment.html>