Google cookbook - Mocking Nonvirtual Methods

[geira]

Hi. I understand that mocking non-virtual methods should be avoided.
But could someone explain the example in
http://code.google.com/p/googlemock/wiki/CookBook#Mocking_Nonvirtual_Methods
?

How could this be useful? I cannot just switch my concrete class with
the mock object class without changing my legacy code, and if doing so
I could just as well refactor my code to use an interface instead of
my concrete class. So, what's the point I've missed here

[Zhanyong Wan (λx.x x)]

Hi,

This is useful when you are squeezing performance.

Calling a virtual function is slower than calling a non-virtual
function, and makes it hard for the compiler to perform certain
optimizations. Therefore there is a cost in using virtual functions.
In most cases, that's not a problem as the overhead is usually
negligible. However, in some cases you absolutely need every bit of
performance you can get, meaning that you may not be able to afford
virtual functions.

--
Zhanyong

[geira]

Ok. I think I misunderstood the intention of mocking concrete methods?
In the example (see http://code.google.com/p/googlemock/wiki/CookBook#Mocking_Nonvirtual_Methods),
you cannot just in a test case just replace the ConcretePacketStream
with the mock object MockPacketStream, so my question was more like
how do I use it?

Example: Say I want to use the MockPacketStream to test a method
MyConnectionHandler::createConnection(ConcretePacketStream
*pStream);

--
GeirA

On Apr 15, 8:51 am, Zhanyong Wan (λx.x x) <w...@google.com> wrote:
> Hi,
>

> On Tue, Apr 14, 2009 at 11:33 PM, geira <geir.anton...@gmail.com> wrote:
>
> > Hi. I understand that mocking non-virtual methods should be avoided.
> > But could someone explain the example in

> >http://code.google.com/p/googlemock/wiki/CookBook#Mocking_Nonvirtual_...

[Bruce Trask]

I think this section is a bit confusing. It should include a context of how it is used. The key sentence is "This technique can only be used in template code, as shown in the above example."

So for your example:

MyConnectionHandler::createConnection(ConcretePacketStream *pStream);

That function has to to be

template<typename T>
void createConnection(T* pStream)
{
//...
}

or MyConnectionHandler has to be a class template

template<typename T>
class MyConnectionHandler
{
public:
void createConnection(T* Stream);
}

and then in your test case you can instantiate the template with either
the ConcretePacketStream or the MockPacketStream

TEST(Stream, createPacketStream)
{
MyConnectionHandler<MockPacketStream> mch;
MockPacketStream mpt;
// set expectations on mpt ...
mch.createPacketStream(&mpt)
}

or in the case of a member template

TEST(Stream, createPacketStream)
{
MyConnectionHandlermch;
MockPacketStream mpt;
// set expectations on mpt ...
mch.createPacketStream(&mpt)
}

Regards,
Bruce

--- On Wed, 4/15/09, geira <geir.a...@gmail.com> wrote:

[Zhanyong Wan (λx.x x)]

Thanks for the examples, Bruce.

Geir, the recipe says "Then you tell your template code which
implementation to use by instantiating it with different template
arguments." I agree it's a bit too abstract and will benefit from
some concrete examples. I'll edit the wiki soon to add Bruce's
examples.

Cheers,

--
Zhanyong