[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