unknown
1970-01-01 00:00:00 UTC
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.
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.
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.
CATCH does not completely fit my preferred coding styles, but I'll be
open minded :-)
inside SOCI, right?
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.
related DBMS is pointless.
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
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.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.
I meant packages deploying, like its common to have Boost headers 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.
That's pity indeed, I share your concerns.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.
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 fixthe 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.
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.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?
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.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.
Fair point.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.
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 headersinside 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.Good question :-) I'm really not sure if we need it at all, what are we
going to mock exactly?
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 fromrelated 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.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?
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