Re: [Boost-users] Library Interface Design

From: Scott Meyers (usenet_at_[hidden])
Date: 2006-09-14 00:59:50

Rush Manbert wrote:
> In  a case like the example, where I know it might be hard to setup the 
> object correctly, I'd rather have a constructor that took some bogus 
> argument type that set the object up in "simulated success" mode, but 
> only in my debug build.

I'm glad you mentioned this, because my recent knowledge of unit testing 
comes from books like Beck's "Test-Driven Development" and Feathers' 
"Working Effectively with Legacy Code" as well as countless breathless 
articles lauding the wonder of unit testing and showing how it's all 
oh-so-simple.  My feeling is that it would often be convenient to have a 
special "test" interface, but I've never seen any discussion of doing 
that.  I can imagine a couple of ways of doing this, one being to 
literally have a different interface for debug builds, another to have 
"test only" interface elements cordoned off somewhere by convention 
(similar to Boost's use of namespaces named "detail").

> EventLog::EventLog (bool dummyarg)
> {   // This constructor sets us up in simulated success mode.
>      #ifdef DEBUG	// or whatever you use
>          m_simulateSuccess = true;
>      #else
>          throw something useful
>      #endif
> }

Hmmm, I'd think this entire constructor would exist only in debug 
builds, e.g.,

   class EventLog {
   public:
   #ifdef DEBUG
     EventLog(bool dummyarg);
   #endif

Unfortunately, conditional compilation is not without its own resultant 
spaghetti code and concomitant maintenance headaches.

Scott