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 <[email protected]> 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<[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! > > 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 > _______________________________________________ Mailing list: https://launchpad.net/~drizzle-discuss Post to : [email protected] Unsubscribe : https://launchpad.net/~drizzle-discuss More help : https://help.launchpad.net/ListHelp
