← Back to team overview

drizzle-discuss team mailing list archive

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


Grr, well, I did agree with Monty until he disagreed with himself and
agreed with me.  Heck, I don't know any more! ;)

On Mon, Apr 5, 2010 at 3:49 AM, Monty Taylor <mordred@xxxxxxxxxxxx> wrote:
> 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
>>>> 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!
> 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.
> Monty