From: James Dennett (jdennett_at_[hidden])
Date: 2006-09-14 23:49:34
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