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

Reply via email to