[Bf-committers] GSoC Proposal: Unit Testing

[Keir Mierle]

On Fri, May 7, 2010 at 4:09 PM, Leif Andersen <leif.a.andersen at gmail.com>wrote:

> I have a feeling it is me who boarked my installation, not a problem with
> the framework itself.  (I've tried both ubuntu's pre-built binaries, as
> well
> as the files from the link you gave me).  I think it's on there somehow,
> because when I do a tab-completion for the text gtest, I get: gtest-config
>  gtester         gtester-report.  Also, eclipse seems to think
> <gtest/gtest.h> exists.
>
> I basically built sample 1, and here is an error I get:
>

Can you also include the command line to build?


> Multiple markers at this line
> - undefined reference to `testing::Test::Test()'
>  - undefined reference to `testing::internal::GetTestTypeId()'
> - undefined reference to `testing::internal::MakeAndRegisterTestInfo(char
> const*, char
>  const*, char const*, char const*, void const*, void (*)(), void (*)(),
>  testing::internal::TestFactoryBase*)'
>

This looks like a straigtforward missing library problem when linking. Did
you link gtest? I believe -lgtest will do, provided your library search
paths are set correctly.


> on line 79: TEST(FactorialTest, Negative) {
>
>
> I basically get that for every method I use.  (I also get errors saying
> things like EXPECT_EQ doesn't exist, but it seems to stem from this).  Also
> note that I'm using eclipse with gcc to compile the code (as I didn't want
> to build a makefile for the two other files in the sample).


It's a one liner

g++ -o example example.cc -lgtest


>  This error
> causes me to think that it's improperly linked somehow.  However,  line 48
> says: #include <gtest/gtest.h>, and eclipse isn't complaining about that
> code not existing, which causes me to think that I somehow boarked my
> install.


Note that #include does not imply link. You need to include the right
headers for the object file to compile (the .o) and then you need the right
libraries specified with -lfoo when linking to get the final ELF binary.

I suggest using the command line for a bit to make sure you understand how
the compiler and linker are different and how they work together. Otherwise,
trying to track down eclipse problems is really tough because there are
added layers of abstraction that hide the issues.

 (if I did, it's not the end of the world, I was planning on
> reloading this computer in about a week anyway, I can just move that up to
> tonight or tomorrow).
>
> Note that CTest is not a unit testing framework. All CTest does is offer
> the
> > ability to invoke binaries specified in a the CMakeLists.txt files, and
> > report success or fail on a per-binary basis depending on whether the
> > binary
> > had a non-zero exitcode.
>
>
> Erm, that's what I meant, I just couldn't find an eloquent way of saying
> it.
>  Thank you though.  Also, if calling it a unit test framework is a bad
> idea,
> what is a good term for it, or is that the most concise way to say was
> CTest
> is?
>

It's a test runner framework, or maybe a continuous build platform.


> Note that you don't have to *use* C++ at all to use the testing framework.
> > Here's a complete sample  that only has visible C++ in the main function,
> > which itself will not appear in the individual C++ test files.
>
>
> Yes, at least I thought all C code (well, except for the extremely specific
> portions of C code),  were comparable with C++, thus C++ is a superset of
> C.
>  What I was mainly trying to say is how happy would everyone be if the unit
> tests were written in C++.  Although now that I think about it, it's
> probably not too big of a deal.  There are already portions of it written
> in
> C++, so I wouldn't imagine that using gtest would add much baggage (or am I
> wrong to think that?)
>

Hopefully not. I could imagine objections to having to use C++ syntax to
write tests, but that's not the case here.


> Again, thank you for your help.  And I'm sorry if this email is a bit
> difficult to read, I wrote it from the inside out.
>

No problem!

Keir


>
> ~Leif Andersen
>
> ----------
> That was easy:
> http://www.appbrain.com/app/net.leifandersen.mobile.android.easybutton
>
>
> On Fri, May 7, 2010 at 15:51, Keir Mierle <mierle at gmail.com> wrote:
>
> > On Fri, May 7, 2010 at 2:37 PM, Leif Andersen <leif.a.andersen at gmail.com
> > >wrote:
> >
> > > Okay, I have spent several hours looking into this.  I do like how the
> > > framework works, however, I still haven't gotten it to actually compile
> > > anything (not even their samples, so I'm thinking I've got the
> framework
> > > compiled incorrectly).
> >
> >
> > If you can post errors, I may be able to help. Generally installation
> > should
> > be trivial, so I'm a surprised you had issues. If it's something that
> needs
> > to be fixed in Google Test's source or docs, I can do that, so please
> > follow
> > up.
> >
> >
> > >  It also seems like this is designed to be used
> > > directly by the end programmer, rather than being plugged into another
> > > framework such as Ctest (which is what I was considering doing, as
> cmake
> > is
> > > already used), but I could be wrong on that.
> > >
> >
> > I use Google Test and CTest in my own open source project, libmv, to
> great
> > effect.
> >
> > http://libmv.googlecode.com/
> >
> > Note that CTest is not a unit testing framework. All CTest does is offer
> > the
> > ability to invoke binaries specified in a the CMakeLists.txt files, and
> > report success or fail on a per-binary basis depending on whether the
> > binary
> > had a non-zero exitcode.
> >
> > Google Test is a unit testing framework, where you write many small
> tests,
> > each in a function, that get executed all at once in a single binary.
> > Generally, you would make one binary for a suite of tests. For example,
> > there would be a test binary for the sculpt code which has many
> > sculpt-related unit tests.
> >
> >
> > > However, I would like to get the general mood of the developers on
> having
> > a
> > > C++ testing framework.  Is it proffered, acceptable but not optimal, or
> > is
> > > a definite no (or something else).  While the majority of the code is
> > > written in C (except for parts written in python), there are a few bits
> > > here
> > > and there in C++.
> > >
> >
> > Note that you don't have to *use* C++ at all to use the testing
> framework.
> > Here's a complete sample  that only has visible C++ in the main function,
> > which itself will not appear in the individual C++ test files.
> >
> > #include <gtest/gtest.h>
> >
> > TEST(MyTestGroup, EnsureThatFooReturnsPositive) {
> >  EXPECT_GE(foo(), 0);
> > }
> >
> > // more tests here
> >
> > int main(int argc, char **argv) {
> >  ::testing::InitGoogleTest(&argc, argv);
> >  return RUN_ALL_TESTS();
> > }
> >
> > If the main is already linked in elsewhere (as most projects do, see e.g.
> > libmv), then this reduces to just:
> >
> > #include <gtest/gtest.h>
> >
> > TEST(MyTestGroup, EnsureThatFooReturnsPositive) {
> >  EXPECT_GE(foo(), 0);
> > }
> >
> > With any of the C based frameworks, either they require explicit
> > registration or some sort of nasty preprocessing hack in order to get
> this.
> >
> > Keir
> >
> > Anyway, I appreciate your opinions.
> > >
> > > ~Leif Andersen
> > >
> > > ----------
> > > That was easy:
> > > http://www.appbrain.com/app/net.leifandersen.mobile.android.easybutton
> > >
> > >
> > > On Wed, May 5, 2010 at 17:51, Leif Andersen <leif.a.andersen at gmail.com
> > > >wrote:
> > >
> > > > Great, thanks, that's good information to have.
> > > >
> > > > ~Leif Andersen
> > > >
> > > > ----------
> > > > That was easy:
> > > >
> http://www.appbrain.com/app/net.leifandersen.mobile.android.easybutton
> > > >
> > > >
> > > > On Wed, May 5, 2010 at 15:51, Tom M <letterrip at gmail.com> wrote:
> > > >
> > > >> On Wed, May 5, 2010 at 1:41 PM, Leif Andersen <
> > > leif.a.andersen at gmail.com>
> > > >> wrote:
> > > >> > Okay, I'll take a look into it.  The only think that I may be
> > worried
> > > >> about
> > > >> > is the license, I'm not sure how that would work for unit testing,
> > so
> > > >> I'm
> > > >> > not sure if the BSD license would be comparable with a GPL
> project.
> > > >>
> > > >> BSD, MIT, zlib, LGPL are all GPL compatible.
> > > >>
> > > >> LetterRip
> > > >>
> > > >>
> > > >> >
> > > >> > ~Leif Andersen
> > > >> >
> > > >> _______________________________________________
> > > >> Bf-committers mailing list
> > > >> Bf-committers at blender.org
> > > >> http://lists.blender.org/mailman/listinfo/bf-committers
> > > >>
> > > >
> > > >
> > > _______________________________________________
> > > Bf-committers mailing list
> > > Bf-committers at blender.org
> > > http://lists.blender.org/mailman/listinfo/bf-committers
> > >
> > _______________________________________________
> > Bf-committers mailing list
> > Bf-committers at blender.org
> > http://lists.blender.org/mailman/listinfo/bf-committers
> >
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers
>