Re: [Boost-users] Library Interface Design

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