> > > Write a class, which consists of one function - MAPILogonEx - and use
> > > its instance as a parameter when calling Logon()? That doesn't sound
> > > good.
> > It's just a function, right? Here are two techniques:
> > 1) If you have your class in files named wrmapisession.h, and
> > wrmapisession.cpp make another file called testwrmapisession.cpp. Is
> > be empty except for this line:
> Hi Michael!
> Looks like a nice solution. C++ isn't one of my languages...in Delphi
> learned that a problem like this is a smell that there is a violation of
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 trick
just to get past all of that direct API usage, to deal with one problem at a
Quote:> That's why I'd move to an adapter based on an interface, with an interface
> 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 go
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 paying
attention to duplication and feature envy. The nice thing is, with the mock
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 healthy
abstraction, something more than just an adapter.