← Back to team overview

drizzle-discuss team mailing list archive

Re: GSoC - Add a Proper Unit Testing Framework to Drizzle

 

Hi all!


On 03/29/2010 04:00 PM, Jay Pipes wrote:
On Mon, Mar 29, 2010 at 5:13 PM, Paweł Blokus<pblokus@xxxxxxxxx>  wrote:
The project's first steps, however, should focus on simply
constructing a solid unit testing framework and integrating that into
our build process.  I would *strongly* recommend using an existing
open source unit testing framework such as GTest.

I was thinking whether I could do this step now and provide some unit
tests as my low-hanging-fruit tasks.

Absolutely! That would be very good.

I took a few passes through Pawel's branch this weekend. It's a good start and has made me actually spend a bit considering this, so I now have some thoughts.

However, I'm not sure what I would need to do in order to integrate
the unit testing framework with the building process. Some points that
come to my mind are:

1. Checking the presence of the unit testing library while running configure

yep, and monty taylor can help you with these kind of things.

I have done this in my modified version of the branch.

2. adding all the new files into the make procedure

kind of.  you would have an include.am file in a unittest/ directory
(or similar)

Pawel had this done in his branch.

3. adding a new build target like 'make unittest' which would run the tests

Yep, in the main root directory's Makefile.am.  Again, monty may have
some ideas on how best to structure changes to the configure and
makefiles, though.  I will defer to his judgment here.

No- the unittests should be added to the automake testing system as check_PROGRAMS. I have done this in my version of Pawel's branch. This way the unittests get run on make check and on make distcheck and the output gets integrated in a decent manner.

I have the feeling that I'm totally missing something and it might
turn out to take a lot more work than I would expect. Anyway I would
appreciate any feedback :)

Nope, shouldn't actually be too difficult to get a simple framework up
and running.  You can also check out how projects like Google
Protobuffers do their unit testing.

Like I said, the branch looked good... I've made two versions of it - one that does all of the build stuff it needs to do:

lp:~mordred/drizzle/unittests

and then one that replaces google test with boost::test.

lp:~mordred/drizzle/boost-unittests

Pros and cons as I see it so far:

We're already forcing developers to have boost installed. Since they have a C++ testing framework that's very similar to google test already - we can use it and not have any additional build depends. Since it's unittesting - we also still don't have any additional install depends.

Google Test is slightly nicer in how it outputs results right out of the box, although slighly uglier in linking (you have to link with a different version of the library to get their auto-generated main function, whereas boost generates one for you in the header if you ask for one). But - google test introduces yet-another build depend on gtest. I'm not opposed this, of course - but I think that since they are _really_ similar (honestly, it looks like google test is based on boost::test) it should be demonstrated that there is a clear advantage of gtest over boost::test for us to choose gtest over boost::test.

Anyway - check out the two branches and see what you think. Thanks for getting this ball rolling Pawel!

Monty



Follow ups

References