On Mon, 8 Apr 2013 16:56:20 +0100 Mateusz Loskot <mate...@loskot.net> 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 (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. ML> BTW, I know Phil is going to give talks about CATCH during a few upcoming ML> conferences in UK, so that is a good indicator the project is active. Also, knowing how these things happen, he'll probably have a few things to fix/improve in CATCH too after these talks... 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. 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. 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? 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... 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. Thank you for driving this process! VZ
pgphjmYj7E1DP.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 soci-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/soci-users
