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