On Sun, 7 Apr 2013 04:52:48 +0100 Mateusz Loskot <[email protected]> wrote:
ML> Here are some of my more important points: ML> ML> Using gtest + gmock will effectively add two new ML> dependencies to SOCI. Same for CATCH + Turtle (or other mocker). ML> Using Boost.Test + Turtle (Boost.Mock) will add, let's say, one (Turtle) ML> and 'half' (Boost). Currently Boost is optional but I suppose many if not ML> most users build SOCI with Boost, same for packes. ML> If someone has Boost installed, I think it's safe to assume it's complete ML> Boost distribution, so there are Boost.Test headers available ML> (if we are header-only-philic here, we'll be fine :-)). ML> Another important advantages of Turtle is that its interface, style and ML> conventions match Boost's. This promises seamless integration. Hello, I think the dependency point is pretty important for the testing framework. Of course, for any developer of the library it's not difficult to install either one of the libraries mentioned above (or all of them :-) but this is not the only case where the dependencies matter. I'm thinking more about the users who may be asked to run the SOCI tests, perhaps with some small changes, to help debugging some problem. And also about occasional contributors who'd have much higher probability of updating the tests if they didn't need to install anything extra to be able to run them. From this point of view, CATCH is perfect IMHO because it's just a single header, that could (and should) be included in SOCI sources themselves. Boost.Test can be used in header-only mode but this is not its preferred mode of operation and it's not explained very clearly in the documentation (AFAIR...) but it's still acceptable. Asking people to compile googletest themselves is much less so. 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
pgpocfGtESwyI.pgp
Description: PGP signature
------------------------------------------------------------------------------ Minimize network downtime and maximize team effectiveness. Reduce network management and security costs.Learn how to hire the most talented Cisco Certified professionals. Visit the Employer Resources Portal http://www.cisco.com/web/learning/employer_resources/index.html
_______________________________________________ soci-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/soci-users
