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 <[email protected]> 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/ > > _______________________________________________ lldb-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/lldb-commits
