[Lldb-commits] [PATCH] Add SBArgs to the public interface

Zachary Turner zturner at google.com
Wed Mar 11 14:59:40 PDT 2015


In http://reviews.llvm.org/D8265#139311, @clayborg wrote:

> I would rather not add API if it is just used for testing and I would prefer to not have this in our public API if we don't need it.
>
> Don't we have some internal based testing beneath the public API walls we can use?
>
> The other way to test if the argument parsing is working is to have a program that dumps arguments and launch this process and verify the arguments by parsing the stdout of the program. I believe we have some tests that do this that were made to test this very thing.


We have gtest C++ based unit tests, but it's not hooked up on all platforms and build systems (notably it doesn't build on Windows yet, or the Xcode build).  Even if it's only for tests now, it certainly seems like it could be integrated into other aspects of the SB API later by someone else.

I don't really like the program dumping thing because it's adding a bunch of layers on top of what I really want to test, which is just the argument parsing.  The shell gets in the way for example, and you can't guarantee that if you call <program> <command-line> that this will end up in a call to Args::SetCommandString(<command-line>) because the shell might have done something.

We need to test that Args::SetCommandString(<command-line>) with known values of <command-line>, parses and tokenizes the way we expect.  I can remove the C++ from the public API, but I kind of think that having an SBArgs is the best way to do this.


http://reviews.llvm.org/D8265

EMAIL PREFERENCES
  http://reviews.llvm.org/settings/panel/emailpreferences/






More information about the lldb-commits mailing list