← Back to team overview

drizzle-discuss team mailing list archive

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

 

I agree with Monty on all his points.  boost::test is the way to go if
we already require Boost as a dependency!

-jay

On Sun, Apr 4, 2010 at 9:08 PM, Monty Taylor <mordred@xxxxxxxxxxxx> 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!
>
> Monty
>



References