> On Sep 15, 2015, at 4:23 PM, d...@burble.org wrote: > >>>>> I do still think we need some tests that verify commands run, but I think >>>>> those tests should focus not on doing complicated interactions with the >>>>> debugger, and instead just verifying that things parse correctly and the >>>>> command is configured correctly, with the underlying functionality being >>>>> tested by the api tests. >>>>> >>>>> Thoughts? > > I agree that we should have both testing methods - SB API *and* commands, > because we should be testing the user command interface too! > > Instead, to fix the Windows vs. other issue, I would suggest writing a > sub-class that won't expect the missing params based on platform. > > 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. But if there's anything you can do with the lldb command line that you can't do with the SB API's that is a bug. Please file bugs (or maybe ask "how would I do that" here first then file a bug if you get no answer.) 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. If we had much more time we might have built the Command Line on top of the SB API's, but that would have made it really hard to bootstrap the thing. In theory, somebody could go back & re-implement the lldb command line on top of the SB API's - much like what was done with the MI commands. In actuality that would be a lot of effort that could be better spent somewhere else. But not doing it that way means we have to be careful not to add stuff to the command line without adding some way to get at it with the API's. Jim > > -Dawn _______________________________________________ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
