Re: Unit Testing Frameworks (was Re: Singletons)
On 12/26/2012 1:45 AM, ?? Tiib wrote:
On Sunday, 16 December 2012 17:27:05 UTC+2, Balog Pal wrote:
On 12/14/2012 1:21 AM, ?? Tiib wrote:
First ... about your idea in general. Making unit tests is difficult
when singular state on what your unit depends is behind free functions
and you use some mocking framework that does not help turning free
functions into mock versions.
Can you give a C++ example for this?
Real world example of free C++ mock framework where mocking free
functions is not implemented: http://code.google.com/p/googlemock/
Or ... at least it was not implemented last I eyeballed it.
Excuse me, but why on earth would one want a *mocking framework* to
create a function? Instead of just writing it and move along with
actual job aimed? Maybe this thing "misses" that utility for its
sitting on the trivial list?
I did write tests for both PFA and singleton scenarios, the difference
in effort was immaterial.
IME you just use its regular
header, then the linker obviously will miss the function body, and you
provide an implementation.
Yes, on general case of free non-template functions without overloads it
is as simple as that.
I'm glad to hear it. :)
And you can help with the preprocessor too defining a macro for the
function name that hijacks it. (the singleton accessor function shall
have a unique name, right?)
Sure, macros can be used too.
When the test is built #include-ing the subject's source rather than
linking with its object, it can be even easier.
In ideal ... one creating a mock framework should try to mock all parts
of GoF patterns plus an equivalent of <algorithm>.
For me it goes pretty much backwards. Tests are there to serve the
program or the dev process, not some abstract aim like covering a book.
Especially a taxonom.
To achieve that
some tricks are needed. Common bad outcome of those tricks is that
continuous integration server spits out rubbish about the mocks of
some of the thousands of unit tests one day and refuses to compile
those.
That rubbish will be very scary if the macros and templates used
in mock framework are complex. OTOH the less scary these are
the more likely it is that the guy who actually caused the issue can
understand and fix it on his own.
If that is a practical problem, it sounds like another point against a
framework, and to focus on actual values.
The frameworks I used for tests only arranged launch of cases and
tabulate the results.
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]