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

Greg Clayton clayborg at gmail.com
Wed Mar 11 15:57:26 PDT 2015


gtest would be my vote. There are bound to be things we need to test that aren't in the API and this is a good way to do this.

The other thing I can think if is if, for debug builds only, we add a static function that is available in the public API that we can call from our test suite. Then we have a python based test that just does something like:

#if defined(LLDB_CONFIGURATION_DEBUG)
static void SBDebugger::RunUnitTests();
#endif

The in python:

debugger.UnitTest()

This runs all built in unit test. These tests might need a output format that can be parsed in case any built in unit test fail. Then all classes that want to run unit tests can register a <classname::UnitTest() static function that can be run.


> On Mar 11, 2015, at 3:25 PM, Zachary Turner <zturner at google.com> wrote:
> 
> It sounds to me like we should just do gtest.  There are already other things that could stand to be unit tested, like the IRInterpreterMemoryMap which I found some bugs in early on when I joined the project, and it's easy to find other examples like RegularExpression.
> 
> 
> http://reviews.llvm.org/D8265
> 
> EMAIL PREFERENCES
>  http://reviews.llvm.org/settings/panel/emailpreferences/
> 
> 





More information about the lldb-commits mailing list