<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">Zach,<div class=""><br class=""></div><div class="">what I might try to do is get a basic test runner in the context of the Xcode build, and then send my patch over to you to see if we can get that same runner building with Makefiles. Then if you have linker problems, we can puzzle over them together.</div><div class=""><br class=""></div><div class="">What do you think?</div><div class=""><br class=""></div><div class="">Sean</div><div class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Oct 2, 2014, at 6:11 PM, Zachary Turner <<a href="mailto:zturner@google.com" class="">zturner@google.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class="">I gave it a brief look, but I didn't get it working. Clang and LLD both already do this, so I figured it would be as simple as copying their CMake for the gtest stuff and fixing it up with LLDB paths. Unfortunately, I was getting tons of linker errors, and I'm not really sure why, as there didn't appear to be much magic there. I didn't investigate it further after that, but it would definitely be a good thing to tackle.</div><div class="gmail_extra"><br class=""><div class="gmail_quote">On Thu, Oct 2, 2014 at 2:01 PM, Sean Callanan <span dir="ltr" class=""><<a href="mailto:scallanan@apple.com" target="_blank" class="">scallanan@apple.com</a>></span> wrote:<br class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word" class=""><div class="">At risk of being burnt at the stake for practicing the the necromantic arts:</div><div class="">Jim’s point that internal APIs are somewhat fragile is well taken, and I don’t think there’s much value in using internal tests as “more convenient” substitutes for external tests.</div><div class=""><br class=""></div><div class="">That said, I think internal unit tests add several benefits that improve code:</div><div class=""><br class=""></div><div class=""><ul class=""><li class=""><i class="">Modular design</i>. If clients of an internal object have to do a lot of extra work to make the object work properly, this may indicate a design issue.</li><li class=""><i class="">State encapsulation</i>. If an object changes behaviors depending on outside state, then that makes it much harder to use.</li><li class=""><i class="">Code readability</i>. Test cases can demonstrate how an object is intended to be used, and act as compelling witnesses that that use case works.</li></ul><div class=""><br class=""></div></div><div class="">I would be interested in using the expression parser as a guinea pig to introduce test-driven methods.</div><div class="">Todd/Zach, did you ever get a gtest-based unit test system working?</div><span class="HOEnZb"><font color="#888888" class=""><div class=""><br class=""></div><div class="">Sean</div></font></span><div class=""><div class="h5"><br class=""><div class=""><blockquote type="cite" class=""><div class="">On Jul 18, 2014, at 6:14 PM, Zachary Turner <<a href="mailto:zturner@google.com" target="_blank" class="">zturner@google.com</a>> wrote:</div><br class=""><div class=""><div dir="ltr" class="">FWIW I'm kind of in favor of bringing in gtest with limited use. When I first started digging into LLDB, probably the first 3-4 bugs I fixed were all in IRMemoryMap, and they would all have been caught if the class were unit tested properly. </div>
<div class="gmail_extra"><br class=""><br class=""><div class="gmail_quote">On Fri, Jul 18, 2014 at 4:03 PM, Greg Clayton <span dir="ltr" class=""><<a href="mailto:gclayton@apple.com" target="_blank" class="">gclayton@apple.com</a>></span> wrote:<br class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
We could expose a new static function in SBDebugger:<br class="">
<br class="">
class SBDebugger {<br class="">
<br class="">
static void<br class="">
UnitTest (const char *args);<br class="">
<br class="">
};<br class="">
<br class="">
Then internally it can parse any arguments and run tests as needed? Each class that wants to register unit tests with the debugger during SBDebugger::Initialize() which must be called prior to doing anything with the LLDB API:<br class="">
<br class="">
<br class="">
SBDebugger::Initialize()<br class="">
{<br class="">
Debugger::Intialize();<br class="">
}<br class="">
<br class="">
Debugger::Initialize()<br class="">
{<br class="">
....<br class="">
NamedPipe:: Initialize();<br class="">
}<br class="">
<br class="">
<br class="">
Then in the static NamedPipe::Initiazize() you could register your unit tests:<br class="">
<br class="">
void<br class="">
NamedPipe::Initialiaze()<br class="">
{<br class="">
Debugger::RegisterUnitTest(NamedPipe::InitTest1, "NamedPipe::InitTest1"));<br class="">
}<br class="">
<br class="">
<br class="">
Then you could just run:<br class="">
<br class="">
SBDebugger::Initialize();<br class="">
SBDebugger::UnitTest(NULL); // Run all tests<br class="">
<br class="">
Or run individual ones:<br class="">
<br class="">
SBDebugger::Initialize();<br class="">
SBDebugger::UnitTest("--test NamedPipe::InitTest1"); // Run just "NamedPipe::InitTest1"<br class="">
<br class="">
Of course then the LLDB test suite could run these unit tests first to make sure everything is good.<br class="">
<div class=""><div class=""><br class="">
<br class="">
<br class="">
> On Jul 16, 2014, at 3:59 PM, Zachary Turner <<a href="mailto:zturner@google.com" target="_blank" class="">zturner@google.com</a>> wrote:<br class="">
><br class="">
> If it makes you feel any better LLVM is leery of it too, and it's only used, as you said, in specialized circumstances. It's especially useful for testing abstract data types, where you just want to test the interface to a self-contained, reusable class.<br class="">
><br class="">
><br class="">
> On Wed, Jul 16, 2014 at 2:25 PM, <<a href="mailto:jingham@apple.com" target="_blank" class="">jingham@apple.com</a>> wrote:<br class="">
> I'm a little leery about this. We don't test at the lldb_private layer because those tests are likely to be fragile and easily broken. For utility classes like NamedPipe I guess I don't so much mind, but I'm not sure its a great idea to do this more generally.<br class="">
><br class="">
> Jim<br class="">
><br class="">
> > On Jul 16, 2014, at 9:40 AM, Todd Fiala <<a href="mailto:tfiala@google.com" target="_blank" class="">tfiala@google.com</a>> wrote:<br class="">
> ><br class="">
> > Hey guys,<br class="">
> ><br class="">
> > Sometimes I have smaller bits of code I'd like to test in LLDB as I'm developing them (i.e. TDD-style) that are C++ and won't be exposed directly via Python. I'm not sure I've seen any facilities in the LLDB tests for adding such tests. Essentially I'd want to do something like a gtest or cppunit test.<br class="">
> ><br class="">
> > Do we have any mechanism for doing that currently? If we do, what is it? If we don't, how about adding some mechanism to do it after we figure out how we'd like to approach it? Or, if you have thoughts on a good, simple way to do it from Python that doesn't require extra Python bindings just to do it, that'd be fine by me as well.<br class="">
> ><br class="">
> > If we want to take a concrete example, here is one: I'm adding a NamedPipe class under the host dir. I'd like to make some simple tests for it, and test it under Linux, Windows and MacOSX. In the case of Windows, it would be the only real way for me to test that it's behaving exactly as I want at this point. This isn't the only time I've wanted C++-level tests at a fairly fine granularity, but it's a good example of it.<br class="">
> ><br class="">
> > Any thoughts?<br class="">
> > --<br class="">
> > Todd Fiala | Software Engineer | <a href="mailto:tfiala@google.com" target="_blank" class="">tfiala@google.com</a> | <a href="tel:650-943-3180" value="+16509433180" target="_blank" class="">650-943-3180</a><br class="">
> ><br class="">
> > _______________________________________________<br class="">
> > lldb-dev mailing list<br class="">
> > <a href="mailto:lldb-dev@cs.uiuc.edu" target="_blank" class="">lldb-dev@cs.uiuc.edu</a><br class="">
> > <a href="http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev" target="_blank" class="">http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev</a><br class="">
><br class="">
> _______________________________________________<br class="">
> lldb-dev mailing list<br class="">
> <a href="mailto:lldb-dev@cs.uiuc.edu" target="_blank" class="">lldb-dev@cs.uiuc.edu</a><br class="">
> <a href="http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev" target="_blank" class="">http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev</a><br class="">
><br class="">
> _______________________________________________<br class="">
> lldb-dev mailing list<br class="">
> <a href="mailto:lldb-dev@cs.uiuc.edu" target="_blank" class="">lldb-dev@cs.uiuc.edu</a><br class="">
> <a href="http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev" target="_blank" class="">http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev</a><br class="">
<br class="">
</div></div></blockquote></div><br class=""></div>
_______________________________________________<br class="">lldb-dev mailing list<br class=""><a href="mailto:lldb-dev@cs.uiuc.edu" target="_blank" class="">lldb-dev@cs.uiuc.edu</a><br class=""><a href="http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev" target="_blank" class="">http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev</a><br class=""></div></blockquote></div><br class=""></div></div></div></blockquote></div><br class=""></div>
</div></blockquote></div><br class=""></div></body></html>