[lldb-dev] Testing through api vs. commands

[Greg Clayton via lldb-dev]

> 
> So in summary, it sounds like we agree on the following guidelines:
> 
> 1) If you're committing a CL and it is possible to test it through the SB API, you should only submit an SB API test, and not a HandleCommand test.

agreed

> 2) If you're committing a CL and it's not possible to test it through the SBI API but it does make sense for the SB API, you should extend the SB API at the same time as your CL, and then refer back to #1.

agreed

> 3) If it is not possible to test it through the SB API and it does not make sense to add it to the SB API from a design perspective, you should consider writing a unit test for it in C++.  This applies especially for utility classes and data structures.

agreed

> 4) Finally, if none of the above are true, you can write a HandleCommand test.

agreed
> 
> One more question: I mentioned earlier that we should enforce the distinction between HandleCommand tests and python api tests at an organizational level.  In other words, all HandleCommand tests go in lldb/test/command-api, and all new SB API tests go in lldb/test/command-api.  Eventually the goal would be to only have 3 toplevel directories under lldb/test.  unittests, command-api, and python-api.  But this would take some time since it would be on a move-as-you-touch basis, rather than all at once.  Does this seem reasonable as well?

I really don't care for the "python-api" or "command-api" directories. We should make tests as needed without needing to place them into specific API or command line bins. I don't want two directories like:

test/command-api/lang/c/....
test/public-api/lang/c/....


I would rather us just write the tests as needed and do what is right for the tests. The API/command directories add no value. I am fine with having these directories when say we are trying to compile against the public API as a test in itself, but we don't need to go moving or putting tests into these directories.

Greg