On 8 April 2013 17:28, Vadim Zeitlin <[email protected]> wrote: > On Mon, 8 Apr 2013 16:56:20 +0100 Mateusz Loskot <[email protected]> wrote: > > ML> > ML> Neither CATCH nor Turtle seems to be packaged, > ML> > > ML> > Again, CATCH is not packaged because it doesn't need packaging, this is > ML> > the appealing part. > ML> > ML> I meant packages deploying, like its common to have Boost headers > packaged. > > I see, sorry for the misunderstanding. I didn't realize you were already > using the same approach with TUT
In two projects http://svn.osgeo.org/geos/trunk/tests/unit/tut/ https://github.com/libLAS/libLAS/tree/master/test > (which, BTW, I didn't spend much time on > just because the example on http://tut-framework.sourceforge.net/ is pretty > weird-looking, at least compared to the one at > https://github.com/philsquared/Catch/wiki/Tutorial), so I just wanted to > emphasize this, IMHO important, aspect. I started using it in 2006, given that generation of C++ libraries, TUT is dead simple to use :) > ML> Fair point. CATCH does not completely fit my preferred coding styles, > ML> but I'll be open minded :-) > > Well, the combined header (catch.hpp) is definitely pretty horrible, but > browsing the code in their repository doesn't immediately show anything too > bad. The worst thing I noticed, style-wise, was the use of identifiers > starting with underscores, which should clearly be avoided but OTOH is not > quite a firing offense neither. I agree on both, the critique and relaxing (I personally don't like CamelCase or class I* naming, but one can never have all personal prefs fulfilled :)) > ML> > The main advantages of CATCH are the ease of installation (none needed) > ML> > ML> If we consider CATCH, I assume we will simply host copy of its headers > ML> inside SOCI, right? > > Yes, I think we should put catch.hpp somewhere in our sources. Alternative, at least in development version, is to use Git submodule. In release, the file would be copied of course. > ML> > ML> Why I mention mock every time? > ML> > > ML> > Good question :-) I'm really not sure if we need it at all, what are we > ML> > going to mock exactly? > ML> > ML> Core. I am very keen in exercising mocking techniques against the core. > > I must admit that I don't follow you at all here. For me mocking is used > to replace a component that can't be easily tested (e.g. because it uses an > external data source which is not always available) with a mock-up that > emulates this component in a predictable way and can also be used to verify > that it's used as intended. So if we mock the core itself, what are we > testing then? I wasn't clear. I meant, to test Core with mock backend (i.e. similar to empty, but covering more). But, this idea is still forming, so I'd rather focus on rewriting tests and not waste time discussing details of that vague mocking idea, for the time being. If I have time at some point, I may prepare a prototype, then it will be easier to talk. > ML> > A database backend? > ML> > ML> Nope, backends rely onDBMS specific features, so testing them in > isolation from > ML> related DBMS is pointless. > > My idea was to use mocking to check that the core code calls the > appropriate backend methods, as expected. I'm not sure if this really has > an enormous value but I at least can understand this, unlike the idea of > mocking the core which still has me scratching my head... My idea is exactly the same, I just expressed it badly. > ML> So, to summarise my position, I'd be in favour to start rewriting > ML> tests using CATCH. > ML> Once we start, we should soon be able to confirm if it is lacking any > ML> features or not. > > This would be perfect from my point of view. And the mocking discussion > can probably wait until later. OK, it looks we're set then. CATCH. My short term plan then (details to be discussed on soci-devel or GH issues): 1. Release 3.2.1 2. Reorganise source tree a bit (shuffle stuff, remove unused stuff, etc.) 3. Buried headers 4. In parallel, kickstart tests rewrite and work on integers support > Thank you for driving this process! Thanks great for help! 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
