On Fri, May 7, 2010 at 2:37 PM, Leif Andersen <[email protected]>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 <[email protected] > >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 <[email protected]> wrote: > > > >> On Wed, May 5, 2010 at 1:41 PM, Leif Andersen < > [email protected]> > >> 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 > >> [email protected] > >> http://lists.blender.org/mailman/listinfo/bf-committers > >> > > > > > _______________________________________________ > Bf-committers mailing list > [email protected] > http://lists.blender.org/mailman/listinfo/bf-committers > _______________________________________________ Bf-committers mailing list [email protected] http://lists.blender.org/mailman/listinfo/bf-committers
