Waaaaitasecond, I’m seeing the gtest subproject… it’s a bit embarrassing that I haven’t checked out top of tree in so long! I’m going to take a look around. Still interested in collaborating on this.
Sean > On Oct 2, 2014, at 6:11 PM, Zachary Turner <ztur...@google.com> wrote: > > 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. > > On Thu, Oct 2, 2014 at 2:01 PM, Sean Callanan <scalla...@apple.com > <mailto:scalla...@apple.com>> wrote: > At risk of being burnt at the stake for practicing the the necromantic arts: > 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. > > That said, I think internal unit tests add several benefits that improve code: > > Modular design. 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. > State encapsulation. If an object changes behaviors depending on outside > state, then that makes it much harder to use. > Code readability. Test cases can demonstrate how an object is intended to be > used, and act as compelling witnesses that that use case works. > > I would be interested in using the expression parser as a guinea pig to > introduce test-driven methods. > Todd/Zach, did you ever get a gtest-based unit test system working? > > Sean > >> On Jul 18, 2014, at 6:14 PM, Zachary Turner <ztur...@google.com >> <mailto:ztur...@google.com>> wrote: >> >> 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. >> >> >> On Fri, Jul 18, 2014 at 4:03 PM, Greg Clayton <gclay...@apple.com >> <mailto:gclay...@apple.com>> wrote: >> We could expose a new static function in SBDebugger: >> >> class SBDebugger { >> >> static void >> UnitTest (const char *args); >> >> }; >> >> 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: >> >> >> SBDebugger::Initialize() >> { >> Debugger::Intialize(); >> } >> >> Debugger::Initialize() >> { >> .... >> NamedPipe:: Initialize(); >> } >> >> >> Then in the static NamedPipe::Initiazize() you could register your unit >> tests: >> >> void >> NamedPipe::Initialiaze() >> { >> Debugger::RegisterUnitTest(NamedPipe::InitTest1, >> "NamedPipe::InitTest1")); >> } >> >> >> Then you could just run: >> >> SBDebugger::Initialize(); >> SBDebugger::UnitTest(NULL); // Run all tests >> >> Or run individual ones: >> >> SBDebugger::Initialize(); >> SBDebugger::UnitTest("--test NamedPipe::InitTest1"); // Run just >> "NamedPipe::InitTest1" >> >> Of course then the LLDB test suite could run these unit tests first to make >> sure everything is good. >> >> >> >> > On Jul 16, 2014, at 3:59 PM, Zachary Turner <ztur...@google.com >> > <mailto:ztur...@google.com>> wrote: >> > >> > 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. >> > >> > >> > On Wed, Jul 16, 2014 at 2:25 PM, <jing...@apple.com >> > <mailto:jing...@apple.com>> wrote: >> > 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. >> > >> > Jim >> > >> > > On Jul 16, 2014, at 9:40 AM, Todd Fiala <tfi...@google.com >> > > <mailto:tfi...@google.com>> wrote: >> > > >> > > Hey guys, >> > > >> > > 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. >> > > >> > > 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. >> > > >> > > 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. >> > > >> > > Any thoughts? >> > > -- >> > > Todd Fiala | Software Engineer | tfi...@google.com >> > > <mailto:tfi...@google.com> | 650-943-3180 <tel:650-943-3180> >> > > >> > > _______________________________________________ >> > > lldb-dev mailing list >> > > lldb-dev@cs.uiuc.edu <mailto:lldb-dev@cs.uiuc.edu> >> > > http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev >> > > <http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev> >> > >> > _______________________________________________ >> > lldb-dev mailing list >> > lldb-dev@cs.uiuc.edu <mailto:lldb-dev@cs.uiuc.edu> >> > http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev >> > <http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev> >> > >> > _______________________________________________ >> > lldb-dev mailing list >> > lldb-dev@cs.uiuc.edu <mailto:lldb-dev@cs.uiuc.edu> >> > http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev >> > <http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev> >> >> >> _______________________________________________ >> lldb-dev mailing list >> lldb-dev@cs.uiuc.edu <mailto:lldb-dev@cs.uiuc.edu> >> http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev >> <http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev> > >
_______________________________________________ lldb-dev mailing list lldb-dev@cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
