On 8 April 2013 11:52, Vadim Zeitlin <[email protected]> wrote: > 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. > > I think the dependency point is pretty important for the testing > framework. > [...] > 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.
Vadim, I agree this is an important advantage of using CATCH. I used C++ TUT Framework for similar reasons in two other libraries I founded, where I maintained copy of the framework inside libraries. > 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. Good points. > 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. I meant packages deploying, like its common to have Boost headers packaged. > 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. That's pity indeed, I share your concerns. > 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. On the other hand, using lightweight frameworks like CATCH, it is easier to fix or update it if we need to do so. I've done it with C++ TUT Framework, then contributed fixes upstream. The smaller and simpler the code is, the easier it is to exploit the freedoms promised by FOSS and actually hack code to fit needs :) Another +1 for CATCH. > 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? Good point. BTW, I know Phil is going to give talks about CATCH during a few upcoming conferences in UK, so that is a good indicator the project is active. > Anyhow, to summarize, for me there is the "default" choice which is > Boost.Test and an intriguing new challenger which is CATCH. The choice is narrowing. Good. > 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. Fair point. CATCH does not completely fit my preferred coding styles, but I'll be open minded :-) > The main advantages of CATCH are the ease of installation (none needed) If we consider CATCH, I assume we will simply host copy of its headers inside SOCI, right? > 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? Core. I am very keen in exercising mocking techniques against the core. I do realise it may end up as a complete failure, but I've put it on my personal TODO list, to try it for sake of learning too. It might work :) I don't impose mocking requirements on the new tests. I rather consider mocking as a new feature, an addition that may allow to create real unit tests. Rewriting current tests, which are de facto integration tests, should proceed as refactoring for use with selected testing framework. > A database backend? Nope, backends rely onDBMS specific features, so testing them in isolation from related DBMS is pointless. > 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? Empty backend is generic, so it should qualify well for unit testing. So, to summarise my position, I'd be in favour to start rewriting tests using CATCH. Once we start, we should soon be able to confirm if it is lacking any features or not. Best regards, -- Mateusz Loskot, http://mateusz.loskot.net ------------------------------------------------------------------------------ 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
