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 <[email protected]> wrote: > Hi all! > > > On 03/29/2010 04:00 PM, Jay Pipes wrote: >> >> On Mon, Mar 29, 2010 at 5:13 PM, Paweł Blokus<[email protected]> 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 > _______________________________________________ Mailing list: https://launchpad.net/~drizzle-discuss Post to : [email protected] Unsubscribe : https://launchpad.net/~drizzle-discuss More help : https://help.launchpad.net/ListHelp
