ML> Neither CATCH nor Turtle seems to be packaged,

Again, CATCH is not packaged because it doesn't need packaging, this is
the appealing part.

ML> There are solid communities behind Google and Boost, seems promising.

It was news to me that Boost.Test was still developed, to be honest I was
pretty sure it was abandoned after seeing no changes to it since many
years. It's definitely good to know that Gennadiy is still working on it.
It's less good to know that he still doesn't have time (nor any real plans,
apparently) to update the documentation. More generally, reading the "What
should we do" thread on Boost mailing list didn't inspire me with much
optimism, there seems to be a real disconnect between the users of this
library and its author. Of course, I only skimmed the messages, so maybe my
impression was wrong.

Also, I have to say that I don't care that much about future prospects of
the testing framework because it must already provide everything we need
right now and it must be stable, you definitely don't want your testing
foundations shifting under your feet. And Boost.Test is definitely stable.
Although some hints of planned incompatible changes (let alone the menace
of deprecating it and removing it from Boost entirely) in the thread above
are not really confidence-inspiring neither.

ML> I'm not sure about status of CATCH. I know its author Phil from ACCU.org
ML> and remember there has been load of discussions at the time this library
ML> was forming, but recently it seems slowed down, still not released (?).

This is clearly the main problem with CATCH -- it's too new. We don't
really know anything about its track record and can't really be sure about
its future development. But, again, if it satisfies us right now, in its
current form, does it really matter?


Anyhow, to summarize, for me there is the "default" choice which is
Boost.Test and an intriguing new challenger which is CATCH. I don't
consider googletest at all because it's an extra (compiled) dependency and
because, after using/looking at several Google C++ libraries, I just don't
like them that much, the code quality is IMNSHO much higher in Boost than
in Google C++ code.

The main advantages of CATCH are the ease of installation (none needed)
and the automatic generation of assertion failure messages which is IMO
very nice. But it could have drawbacks that I'm not aware of just because I
didn't use it enough, while with Boost.Test we can be pretty sure to not
have any unpleasant surprises. But the status of Boost.Test as a de facto
standard unit testing library for C++ is quite a bit more doubtful to me
now that I read that thread on boost mailing list. To be honest, I could
never imagine that its removal from Boost would be seriously considered and
even if it doesn't, as I hope, happen, it's still worrisome.


ML> Unless a solid reason appears that will back up one option, I think the
ML> choice will be made driven by "self-regulated natural forces of
ML> community" (tm) :-), that is at some point someone will start rewriting
ML> tests, will make no-brainer decision choosing her/his preferred testing
ML> framework and complete certain substantial amount of work in this area.

I definitely agree with this. Whoever does, chooses.

ML> Why I mention mock every time?

Good question :-) I'm really not sure if we need it at all, what are we
going to mock exactly? A database backend? If so, I think it would be
simpler and better (more flexible) to just clone the existing empty backend
into some "trace" or "debug" backend. Or am I missing some other plan here?

Regards,
VZ

--683890889-41-1365418379=:8484
Content-Type: APPLICATION/PGP-SIGNATURE

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (MingW32)

iEYEABECAAYFAlFioYsACgkQBupB3k9sHoZnhwCgh+G8PvorN68NC8fQxrNKiyY0
2MMAn0J2dj+uJxkZVsJtz/u2QAy9JNjm
=Sh3+
-----END PGP SIGNATURE-----

--683890889-41-1365418379=:8484--