Scott Meyers wrote:
David Abrahams wrote:
I'd much rather develop a library of mock objects for testing. Okay a conforming mock stream may be a little work to write, but you write it once and you're done.
I take this to mean that you have not found it necessary/desirable/useful to create separate test and client interfaces. Okay.
My understanding is that the ability to drop in mock objects requires programming to an interface that can be either a "real" object or a mock object, which in turn suggests using either a template parameter or a base class. Suppose, for example, you have this:
class BigHonkinHairyClass { ... // expensive to construct };
and you want to implement some function f that takes a BigHonkinHairyClass as a parameter. The straightforward declaration would be
void f(BigHonkinHairyClass& bhhc); // maybe const, doesn't matter
But now it's hard to drop in a mock. So I assume you'd modify the interface to be either
template<typename T> void f(T& bhhc); // T must more or less model // BigHonkinHairyClass
or this:
class BigHonkinHairyBase { ... // interface to program against -- }; // uses virtuals
class BigHonkinHairyClass: public BigHonkinHairyBase { ... };
class MockHonkinHairyClass: public BigHonkinHairyBase { ... };
void f(BigHonkinHairyBase& bhhc);
Is that correct? In other words, you'd come up with an interface that let clients do what they wanted but that was also mock-friendly for testing purposes? That is, you'd take testability into account when designing your client interface?
That's about what I've found best when building well-tested code, and it fortunately usually also leads to cleaner designs with little coupling that compile nice and quickly even given current slow C++ compilers. -- James