[LLVMdev] [Patch] Adding unit tests to LLVM

Misha Brukman brukman at gmail.com
Sun Dec 28 09:47:56 PST 2008


2008/12/27 Talin <viridia at gmail.com>

> Misha Brukman wrote:
> > I think this is a great idea!  As Keir already noted, I would also
> > agree with LLVM snapshotting a copy of googletest, but I think it
> > should live in llvm/test/googletest (rather than top-level), since
> > it's not going to be linked into anything outside of llvm/test.
>
> So as far as putting things in llvm/test, I have a question - the
> makefile in that directory contains a whole bunch of rules for
> interfacing with DejaGNU. The unit tests don't (and, I think, shouldn't)
> require any dependence on DejaGNU -- in fact, I'm hoping it will be
> possible to run the unit tests with only the base LLVM package, without
> all of the additional package installations required to run the other
> LLVM tests. I'm just wondering if it will be a problem organizing the
> makefile so that the unit tests don't have any dependence on the other
> tests.
>

I agree, the unittests and DejaGNU shouldn't depend on each other.  If they
are different make targets, would that solve the issue?  For example, the
nightly tester would run "make all" which runs "make check-local", while
unittests could under the "unittest" target, and they won't interfere,
right?

Eventually, the unittests should also be run by default under the "all"
target.

> * Instead of this:
> > EXPECT_TRUE(uintMap.find(0u) == uintMap.begin());
> > is it possible to use EXPECT_EQ() as well?
>
> In order to use EXPECT_EQ, both arguments have to be printable, although
> you can make anything printable by adding the necessary stream operator
> overloads. In this particular case, I decided that the printed
> representation of an iterator wouldn't be meaningful, so I didn't bother
> defining those overloads.


OK, makes sense, thanks.

Misha
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20081228/9b8d2c45/attachment.html>


More information about the llvm-dev mailing list