[Bf-committers] GSoC Proposal: Unit Testing

[Keir Mierle]

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
>