Mock objects and testing

[Joe Van Dyk]

Say I've written a class that wraps around a particular (complex)
communication service library.

I want to unit test objects that use that communication service.

Is the "best practice" to create a Communication_Service abstract base
class that my Concrete_Communication_Service and my
Mock_Communication_Service both inherit from? (and then use the mock
service when unit testing)

Or would I use templates somehow?

In Ruby, I'd create a mock communication class that just had the same
functions as the real communication class and, when testing, pass in the
mock communication object instead of the real communication object.
But, in C++, the mock and real object need to be of the same type, right?


Right now, I have

class Foo
{
Communication_Service* _communication;
public:
Foo(Communication_Service &comm) : _communication(&comm);
};

Then, in the test driver, I create Mock communication object and give
that to Foo's constructor. And in the real program, I create a real
communication object and give that to Foo's constructor.

(using unit testing when learning C++ is great, by the way. I can't
imagine doing it any other way.)

Thanks,
Joe

 

[Phlip]

Say I've written a class that wraps around a particular (complex)
communication service library.

I want to unit test objects that use that communication service.

I tossed this question onto the Yahoo Groups mailing list called
TestDrivenDevelopment because it's a gooder. Read the answers there.

(My day-job right now is to write unit tests that mock communication
services, so I myself would not want to divulge any trade secrets. Yeah,
that's the ticket

BTW you mock when you don't have a "seam". That's a place to insert tests.
The Sockets themselves make a perfect Seam, so plug your server and client
into a loopback socket, inside one test case, and there's your mocks.

 

[Ian Collins]

Say I've written a class that wraps around a particular (complex)
communication service library.

I want to unit test objects that use that communication service.

Is the "best practice" to create a Communication_Service abstract base
class that my Concrete_Communication_Service and my
Mock_Communication_Service both inherit from? (and then use the mock
service when unit testing)

Another alternative, depending on you code layout, is to provide a mock
version of the class implementation in your test code and the real one
in a library the test code for the clients doesn't link.

Or would I use templates somehow?

In Ruby, I'd create a mock communication class that just had the same
functions as the real communication class and, when testing, pass in the
mock communication object instead of the real communication object. But,
in C++, the mock and real object need to be of the same type, right?


Right now, I have

class Foo
{
Communication_Service* _communication;
public:
Foo(Communication_Service &comm) : _communication(&comm);
};

Then, in the test driver, I create Mock communication object and give
that to Foo's constructor. And in the real program, I create a real
communication object and give that to Foo's constructor.

A common solution.

(using unit testing when learning C++ is great, by the way. I can't
imagine doing it any other way.)

Not just when learning.

 

[Daniel T.]

Say I've written a class that wraps around a particular (complex)
communication service library.

I want to unit test objects that use that communication service.

Is the "best practice" to create a Communication_Service abstract base
class that my Concrete_Communication_Service and my
Mock_Communication_Service both inherit from? (and then use the mock
service when unit testing)

Or would I use templates somehow?

First we have to ask some questions:

Given class B uses an object of type A (ie some object that conforms to
the interface of type A.)

Do we know, at compile time, which types of A's are used by our Bs?

Do different B objects use different sub-types of A?

If the answer to the above is "yes", do B objects change which sub-type
of A object they use during their lifetimes?

If the answer to the first question is "no" or the answer to all three
questions are "yes", then I suggest:

class B {
A* a;
public:
B( A* a_ ): a( a_ ) { }
void changeA( A* a_ ) { a = a_; } // if answer 3 is "yes"
// ...
};

This is the only possible solution because we can't say what sub-type of
A, any particular B will use until after the program starts running. Be
careful of lifetime issues though. (for example, ~B and 'changeA' might
need to delete 'a'.)


If the answers are "yes, yes, no", then I suggest:

template < typename A >
class B {
A a;
public:
// ...
};

Here different B's can use different kinds of A's.

If the answers are "yes, no, no", (I suspect this is the case for you)
then the above solutions are overkill. Simply do this:

#include "A.h"

class B {
A a;
public:
//...
};

In your test code, you would use one "A.h" file, in your production code
you use a different "A.h" file.