Hmmm...so you're saying that by mocking the function, you are delaying theQuote:> I've
> > learned that a problem like this is a smell that there is a violation of
> > DIP.
> Yep, the real issue is: why are we mocking at all? If I'm trying to get a
> C++ class into a test harness to add a feature or do some refactoring
> unrelated to the offending functions, I'll often do the dummy function
> just to get past all of that direct API usage, to deal with one problem at
> > That's why I'd move to an adapter based on an interface, with an
> > based factory to generate it. Makes it _very_ easy to swap out test vs
> > production or different production implementations.
> Adapters are great, but I don't like to "settle" the interface too soon.
> Even though a signature like: "HRESULT MAPILogonEx(ULONG ulUIParam, LPTSTR
> lpszProfileName, LPTSTR lpszPassword, FLAGS flFlags, LPMAPISESSION FAR *
> lppSession)" is a crime against nature, often I'll mock it directly by
> adding a method with exactly that signature to a class. Then when I can
> back and forth with the mock and production classes I'll start to make
> higher level methods hat eventually hide the API, often I get them by
> attention to duplication and feature envy. The nice thing is, with the
> function in place, all the code that I move onto the new class can be
> tested. And, that is pretty good because it can safely grow into a
> abstraction, something more than just an adapter.
need to update two interfaces (the production and the test) until the
interface signature defines itself via its needs...if I'm reading right.
That makes more sense to me now.