Hi,
I wrote and use quite extensively http://turtle.sourceforge.net
It still requires some work (and probably 2 or 3 total rewrites in the
process :p) but it meets my needs and overall works better than the
library I was using previously http://mockpp.sourceforge.net
Cheers,
MAT.
_______________________________________________
Boost-users mailing list
Boost...@lists.boost.org
http://lists.boost.org/mailman/listinfo.cgi/boost-users
Hi,
I'm using Google Mock. It's quite powerful and in my opinion very
clear. But you have to write some glue code to make it work with Boost
Test. Something like this:
class BoostTestAdapter: public EmptyTestEventListener {
virtual void OnTestPartResult(const TestPartResult& testPartResult);
{
if (testPartResult.failed()) {
std::stringstream s;
if (testPartResult.file_name())
{
s << std::endl
<< testPartResult.file_name()
<<"(" << testPartResult.line_number() << "): "
<< testPartResult.summary();
}
else
{
s << std::endl
<< "unknown file: "
<< testPartResult.summary();
}
BOOST_ERROR(s.str());
}
}
};
struct GoogleMockFixture {
GoogleMockFixture::GoogleMockFixture()
{
InitGoogleMock(&boost::unit_test::framework::master_test_suite().argc,
boost::unit_test::framework::master_test_suite().argv);
TestEventListeners &listeners = UnitTest::GetInstance()->listeners();
delete listeners.Release(listeners.default_result_printer());
listeners.Append(new BoostTestAdapter);
}
~GoogleMockFixture() {}
};
BOOST_GLOBAL_FIXTURE(GoogleMockFixture)
The error reporting is not perfect yet, but usually you get the source
file and line of the error directly in the error message.
Hope that helps!
Peter
<applause>
That looks like a pretty nice facility.
--
Dave Abrahams
BoostPro Computing
http://www.boostpro.com
Agreed. Is this something you're eventually planning to submit for review?
> [...]I'm using Google Mock. It's quite powerful and in my opinion very
> clear. But you have to write some glue code to make it work with Boost
I can also recommend Google Mock. As it's based on Google Test which is
similar to Boost.Test (basically the same macros with different names)
I've used both Google libraries successfully in projects where I needed a
mocking framework.
Boris
> [...]
On 07/01/2011 19:19, Kenny Riddile wrote:
> Is this something you're eventually planning to submit for review?
Yes that's something I've been thinking about.
I still need to sort out a couple of things regarding the public
interface, then I plan on boostifying it and start gathering some feedback.
Thanks for the motivation boost !
MAT.
> On 07/01/2011 19:19, Joel Falcou wrote:
>> anyway to get this turned into Boost.Mock ?
>
> On 07/01/2011 19:19, Kenny Riddile wrote:
>> Is this something you're eventually planning to submit for review?
>
> Yes that's something I've been thinking about.
> I still need to sort out a couple of things regarding the public
> interface, then I plan on boostifying it and start gathering some
> feedback.
>
> Thanks for the motivation boost !
Hi Matthieu,
I would really like to see a comparison of Turtle with HippoMocks. I am
teaching a class next week and I need to figure out what to recommend
people use/look at. Could you possibly post something?
Thanks,
--
Dave Abrahams
BoostPro Computing
http://www.boostpro.com
_______________________________________________
On Mon, Jan 16, 2012 at 9:50 AM, Dave Abrahams <da...@boostpro.com> wrote:
>
> I would really like to see a comparison of Turtle with HippoMocks. I am
> teaching a class next week and I need to figure out what to recommend
> people use/look at. Could you possibly post something?
If you got a private response on this that you can share, I would
personally like to see it. I started down the road of using Turtle
about a month or so ago before I had to redirect current time to
something different. I liked it, but I admittedly didn't get very
far.
What I found in my situation, though, was that mocking took a
substantial amount of development effort in a "legacy"(*) body of code
such that creating tests that rely upon mocking was more trouble than
it was worth at first evaluation, i.e., it did not save me more time
than it cost. As this was my first experience with an actual mocking
framework (as opposed to ad-hoc bespoke stuff created for a single
purpose), I'm not sure if it's a framework issue, a user (me) issue,
an impedance mismatch between the framework and legacy code, or what.
I suspect that the reality is that it's a little of all of them.
If anybody knows a mocking framework that slides easily into existing,
and sometimes grungy (from a TDD perspective), code base, I'd love to
hear about it.
(*) By "legacy" I mean code that was not written with a test-driven
development mindset.
--
Chris Cleeland
(Disclaimer : I'm the author of Turtle and more importantly I never used
HippoMocks for anything else than toying a bit, so anyone feel free to
correct me if I'm wrong...)
The main difference between the two libraries can be summarized as, given :
struct some_abstract_class
{
virtual void some_method() = 0;
};
With Turtle you need to write the mock class :
struct some_mock : some_abstract_class
{
MOCK_METHOD( some_method, 0 );
};
BOOST_AUTO_TEST_CASE( some_test )
{
some_mock mock;
// use mock...
}
Whereas HippoMocks is able to have you only write :
BOOST_AUTO_TEST_CASE( some_test )
{
MockRepository mocks;
some_abstract_class* mock = mocks.Mock< some_abstract_class >();
// use mock more or less the same way...
}
At this point the question would be : why would you want to use Turtle ? :)
Obviously HippoMocks exploits the compilers implementation defined class
layout in order to hack the function table, but in the end who cares if
it does the job, I suppose.
And it seems to work on a fairly good number of platforms/compilers
according to the documentation.
However because it needs to target classes, they are cases for which
they have to be manually added (when there is no class : for template
meta programming and functors in particular).
Some other cases require writing stub classes also : when a class has
virtual methods and members (this is highlighted in the documentation)
or to mock private methods (because a pointer on a private member
function cannot be accessed).
In the end I believe if the code you write has many public virtual
methods, then the usefulness of HippoMocks is likely high, otherwise
maybe not so much because stub classes seem to be required anyway.
As for the state of both libraries today, I would say the HippoMocks
documentation is a bit sparse and the user/reference manual is lacking,
but the tutorial might be enough to get users started.
I believe Turtle has a slightly better integration with Boost.Test, is a
bit more customizable (error policy, constraint logging, ...) and seems
a more user friendly with compilation errors.
Also Hippomocks doesn't seem to have been updated later than Dec 2010
but it might be that it's stable enough (although the git repository
contains interesting unreleased features I haven't been able to make
work, such as mocking a free function).
I hope this helps,
Mathieu
I don't have the answer to your question but if your legacy code was
developed with "traditional" unit tests, or even without tests, it isn't
going to be easy to introduce mock objects because it actually means
turning everything upside-down.
Using mock objects tends to drive the code to be more "push" (ask others
to do things) and less "pull" (collect data in order to do things) than
the usual. Most of the test cases don't even check any results in the
end, they just expect calls.
It's not just a convenient way of faking components in order to test
them more easily, it's also a way of driving the code a bit differently.
From my experience, trying to use mock objects after a component has
been written results in lengthy test cases which need to configure many
mock objects and/or many expectations in order to work.
I have seen for instance tests like this :
BOOST_AUTO_TEST_CASE( some_test )
{
some_mock a;
MOCK_EXPECT( a.get_some_data ).once().with( -100.f, 100.f
).returns( 0 );
MOCK_EXPECT( a.get_some_data ).once().with( 0.f, 100.f
).returns( 1 );
MOCK_EXPECT( a.get_some_data ).once().with( 100.f, 100.f
).returns( -1 );
// etc... for A LOT of lines
some_class b( a );
b.do_something( 12, 42, 77 );
BOOST_CHECK_EQUAL( 654, b.result() );
}
This is indeed cumbersome to write and hard to maintain, and to someone
accustomed to TDD it's a smell this most likely wasn't. :)
My usual approach is either scrap the component and start from scratch,
or just leave it be if it doesn't impact much the rest of the system...
Mathieu
Paulo Márcio
--
View this message in context: http://boost.2283326.n4.nabble.com/Recommended-mock-framework-to-use-with-Boost-tp3176440p4417063.html
Sent from the Boost - Users mailing list archive at Nabble.com.
Cheers,
Peter
on Thu Jan 19 2012, Mathieu Champlon <mathieu.champlon-AT-masagroup.net> wrote:
> As for the state of both libraries today, I would say the HippoMocks
> documentation is a bit sparse and the user/reference manual is
> lacking, but the tutorial might be enough to get users started.
> I believe Turtle has a slightly better integration with Boost.Test, is
> a bit more customizable (error policy, constraint logging, ...) and
> seems a more user friendly with compilation errors.
> Also Hippomocks doesn't seem to have been updated later than Dec 2010
> but it might be that it's stable enough (although the git repository
> contains interesting unreleased features I haven't been able to make
> work, such as mocking a free function).
>
> I hope this helps,
Thanks for this very complete rundown!
--
Dave Abrahams
BoostPro Computing
http://www.boostpro.com