[lldb-dev] Testing through api vs. commands

[via lldb-dev]

On Tue, Sep 15, 2015 at 04:46:41PM -0700, Jim Ingham wrote:
> > In any case, there's a lot I never could figure out how to do in the SB
> > API that I could only do via commands.  For example, how do you test
> > that a trailing space at the end of the expr --language option's argument
> > is trimmed in the SB API?
> 
> I'm not quite sure I understand what you mean by this example?  It sounds like you are asking how to test peculiarities of the
> Command Line language name option parser through the SB API.  Not sure that makes sense.

See test test_settings_with_trailing_whitespace in test/settings/TestSettings.py.
A test I added here looks like:
        # language
        self.runCmd ("settings set target.language c89")      # Set to known value
        self.runCmd ("settings set target.language pascal ")    # Set to new value with trailing whitespace
        self.expect ("settings show target.language", SETTING_MSG("target.language"),
            startstr = "target.language (language) = pascal")
        self.runCmd("settings clear target.language", check=False)

How would you write this test using the Python API?

> Note, you might have to do some work to marshall information in a way that looks like what some of the complex commands produce.  But even some of the complex printers like the frame & thread Status are available through the SB API's and anything else useful like that should also be exposed at some point.  

I don't think anyone is against using the Python API, but it needs to be easier
to learn and use before folks will adopt it over self.expect.  self.runCmd and
self.expect are straight forward and it's easy to quickly write tests using it.
If you make it too hard to write tests, you'll deter folks from writing tests for
the features they add.

> In theory, somebody could go back & re-implement the lldb command line on top of the SB API's

That would be a cool project to give to some poor college students working on a
branch :)

-Dawn