Hi,
I confess to not having been following this discussion or SOCI development
very closely but to throw my tuppence in
I would highly recommend cppunit as a unit test framework (based on the xunit
framework). I've used it on a daily basis
for many years now (for test driven development)and it does its job very well.
Having moved to cmake you can easily
drive cppunit via ctest.I find it useful to compliment unit tests with program
level tests written as scripts
(each test program can be launched via ctest) but for libraries this generally
isn't necessary.
When using cppunit to test templates we generally test just the significant
specialisations (writing wrappers as necessary
to avoid duplication of code).
I should imagine the requirements for the boost testing framework are a little
different from those of normal libraries as they
do more template meta-programming than most normal human beings care for.
Its worth giving the issue a little thought and experimentation before settling
on one.There are a number of interesting comparisons between frameworks on the
net. E.g.
http://gamesfromwithin.com/exploring-the-c-unit-testing-framework-jungle
Regards,
Bruce.
>________________________________
> From: Alex Ott <[email protected]>
>To: SOCI general discussion list <[email protected]>
>Sent: Sunday, March 24, 2013 9:52 AM
>Subject: Re: [soci-users] Using a unit testing framework?
>
>btw, we can use single-header variant of boost test in case if we
>can't find boost installed:
>http://www.boost.org/doc/libs/1_53_0/libs/test/doc/html/utf/user-guide/usage-variants/single-header-variant.html
>
>On Sun, Mar 24, 2013 at 5:13 AM, Ricardo Fabiano de Andrade
><[email protected]> wrote:
>> Hi all,
>>
>> I also started working on soci recently and I would like to share my opinion
>> regarding the unit tests.
>>
>> First, I already experienced a situation where the only available choice for
>> making a unit test was C assertions.
>> So I'm familiar with the issues and limitations of this solution and I agree
>> that there's great room for improvement.
>>
>> Of course, using such solution was due political disputes but hey, an
>> assert-based test is better than no test at all.
>> If this is not the soci case (the political issue), there's still the case
>> of avoiding external dependencies.
>> Well, almost nothing can be done in this case with the exception of
>> reinventing the wheel (please no).
>>
>> Currently, I'm working with googletest. It's suprisingly simple to get used
>> to and extremely produtive.
>> Besides that it has a great support for testing template classes what can be
>> extremely helpful with soci type support (integers?).
>> Even though googletest is being actively developed and heavly used, I'm
>> afraid it isn't the first option for soci.
>>
>> AFAIK about Boost.Test, it does also support testing template classes
>> (although not that obvious) and so much more - points already enumerated by
>> others in this dicussion.
>> It really haven't changed much in a while but probably because it's already
>> very stable (I still miss the mocking support googlemock has).
>> As others have mentioned before, this would be one of the good options for
>> soci.
>>
>> So being more dependent of the boost libraries can actually be beneficial.
>> If there's a goal of making soci to stick more with the future C++ versions,
>> of course.
>> BTW, soci has been mentioned in the papers/proposals of the next C++
>> standard (see N3612).
>>
>> Finally, the idea behind CATCH (a single header) is awesome but in my
>> opinion the framework is too immature right now.
>> I think soci could eventually be a good place for mutual colaboration
>> causing CATCH to become a stronger option.
>> It's a win-win for both soci (better tests) and CATCH (more collaboration).
>>
>> That's my two cents.
>>
>> Best regards,
>> Ricardo Andrade
>>
>> On Saturday, March 23, 2013, Vadim Zeitlin wrote:
>>>
>>> Hello,
>>>
>>> I've done my first modifications to the SOCI unit tests recently and it
>>> wasn't a very pleasant experience. The 2 main reasons for this are the
>>> rather unusual tests organization and the use of assert() instead of some
>>> more advanced mechanism. I'm especially riled by the latter because
>>> assert() is just not good enough: it doesn't show you which test failed,
>>> it
>>> doesn't show you the values of the variables with which it failed and it
>>> doesn't allow you to continue running past the first failure.
>>>
>>> So I wonder what do you think about using some testing framework instead.
>>> Considering SOCI existing dependencies on Boost it could make sense to use
>>> Boost.Test
>>> (http://www.boost.org/doc/libs/1_53_0/libs/test/doc/html/index.html)
>>> but OTOH all the current dependencies are optional, while this one would
>>> be
>>> semi-required as it's really nice to be able to run tests even if you
>>> don't
>>> use Boost.
>>>
>>> Hence an alternative solution: CATCH. This means "C++ AutomatedTest Cases
>>> in Headers" and, as you can see at https://github.com/philsquared/Catch
>>> [1]
>>> it is just a single header and all you need to do to start using it is to
>>> just include it. It is also really nice in that it's enough to write
>>>
>>> CHECK( ul == 4000000000ul );
>>>
>>> to see the value of "ul" if the test fails, i.e. you have just a single
>>> CHECK() which does everything, whereas with Boost.Test you need to use a
>>> specific macro:
>>>
>>> BOOST_CHECK_EQUAL( ul, 4000000000ul );
>>>
>>> Personally I think this is a great idea but I admit that I haven't used
>>> CATCH in really big test suites so I don't know what effect all the
>>> meta-programming machinery necessary to make the above work has on the
>>> compile times. Still, I believe CATCH would be a good fit for SOCI, so
>>> what
>>> do you think about starting to use it?
>>>
>>> And if not, using Boost.Test would still be much better than relying on
>>> bad old assert()...
>>>
>>> Finally, this is definitely not 3.2-critical but it would be nice to have
>>> an agreement about this before the tests need to be modified the next
>>> time.
>>>
>>> Regards,
>>> VZ
>>>
>>> [1] If you want to see the project activity, look at "integration" branch,
>>> not the default "master".
>>
>>
>> ------------------------------------------------------------------------------
>> Everyone hates slow websites. So do we.
>> Make your web apps faster with AppDynamics
>> Download AppDynamics Lite for free today:
>> http://p.sf.net/sfu/appdyn_d2d_mar
>> _______________________________________________
>> soci-users mailing list
>> [email protected]
>> https://lists.sourceforge.net/lists/listinfo/soci-users
>>
>
>
>
>--
>With best wishes, Alex Ott
>http://alexott.net/
>Twitter: alexott_en (English), alexott (Russian)
>Skype: alex.ott
>
>------------------------------------------------------------------------------
>Everyone hates slow websites. So do we.
>Make your web apps faster with AppDynamics
>Download AppDynamics Lite for free today:
>http://p.sf.net/sfu/appdyn_d2d_mar
>_______________________________________________
>soci-users mailing list
>[email protected]
>https://lists.sourceforge.net/lists/listinfo/soci-users
>
>
>
------------------------------------------------------------------------------
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_mar
_______________________________________________
soci-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/soci-users
