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_S ervice abstract base
class that my Concrete_Commun ication_Service and my
Mock_Communicat ion_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_S ervice* _communication;
public:
Foo(Communicati on_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]

Joe Van Dyk wrote:

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
TestDrivenDevel opment 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.

--
Phlip
http://www.greencheese.org/ZeekLand <-- NOT a blog!!!

[Ian Collins]

Joe Van Dyk wrote:

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_S ervice abstract base
class that my Concrete_Commun ication_Service and my
Mock_Communicat ion_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_S ervice* _communication;
public:
Foo(Communicati on_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.

--
Ian Collins.

[Daniel T.]

In article <Ix********@new s.boeing.com>,
Joe Van Dyk <jo********@boe ing.com> wrote:

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_S ervice abstract base
class that my Concrete_Commun ication_Service and my
Mock_Communicat ion_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.

--
Magic depends on tradition and belief. It does not welcome observation,
nor does it profit by experiment. On the other hand, science is based
on experience; it is open to correction by observation and experiment.