← Back to team overview

drizzle-discuss team mailing list archive

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


On 04/04/2010 06:08 PM, Monty Taylor wrote:
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

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

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:


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


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!

Ok. I take back my backing of boost::test - because we still have to build on CentOS/RHEL 5. The version of boost there is old enough that the API for boost::test is considerably different. It could work - but I believe will wind up being a pain in the ass enough that the extra depend of gtest would be worth it.

So I'm back on gtest with Jay. I'm working on testing gtest across the platforms in our build farm right now - I'll let you know how that goes.


Follow ups