Best simple way to mock static/global function?

I have a simple almost value-like class like Person:

class Person
{
public:
    Person(ThirdPartyClass *object);
    virtual ~Person(void);

    virtual std::string GetFullName() const;
    virtual int GetAge() const;
    virtual int GetNumberOfDaysTillBirthday() const;
};

I'm using a third party library and the Thir开发者_开发技巧dPartyClass needs to have a global/static function called Destroy (part of the 3rd party library) called on it to destroy it. This Destroy function is called in the Person destructor.

Now I'm trying to unit test my Person class and I need a way to mock/stub the Destroy method. I think I could write a wrapper class around the static Destroy function and then use dependency injection to inject this wrapper into the Person class, but it seems like overkill to do that just to call this one function on this simple class. What's a simple straightforward way to do this? Or is dependency injection really the best way to do this?

Update

Ultimately I decided to go with creating a class that wrapped all the 3rd party library's global functions and then using dependency injection to pass this class into the constructor of my person class. This way I could stub out the Destroy method. Although the person class only uses a single function, the other functions of the library are called at other points in my code and as I needed to test those I would face the same issue.

I create a single instance of this wrapper class in my main app code and inject it where needed. I chose to go this route because I think it's clearer. I like Billy ONeal's solution and I think it answers my question, but I realized if I were to leave the code for a few months and come back it would take me longer to figure out what was happening as compared to dependency injection. I'm reminded of the zen of python aphorism "Explicit is better than implicit." and I feel dependency injection makes what's happening a bit more explicit.

Create a link seam. Put your destroy declaration in a header, and then have two implementation files:

// Destroy.cpp
void Destroy()
{
    //Code that really does destruction
}

And for testing:

// DestroyFake.cpp
void Destroy()
{
    //Code that does fake destruction
}

Then link the first file to your main binary, and the second file to your testing binary.

Beyond this, what you ask for is impossible. The linker bakes calls to global functions and static methods into direct jumps into the callee code -- there's no lookup or decision process to hook into to create any type of overload like the one you're looking for (beyond having Destroy calling something that's more easily mocked).

Simple, use Typemock Isolator++ (disclaimer - I work there)

Add 1 line in your test to fake/mock the Destroy

global use:

FAKE_GLOBAL(Destroy);

public statics use:

WHEN_CALLED(Third_Party::Destroy()).Ignore();

private statics use:

PRIVATE_WHEN_CALLED(Third_Party::Destroy).Ignore();

No need for extra code/ No conditional code / No different links.

I'm just playing here, but one approach that might work for you is to provide your own destroy function and disambiguate the call in favour of it by adding a wrapper class around the Third_Party_Lib pointer...

#include <iostream>

namespace Third_Party_Lib
{
    struct X { };
    void destroy(X*) { std::cout << "Third_Party_Lib::destroy()\n"; }
}

template <typename T>
struct Wrap
{
    Wrap(const T& t) : t_(t) { }
    operator T&() { return t_; }
    operator const T&() const { return t_; }
    T t_;
};

namespace Mine
{

#if TEST_MODE
    // this destroy will be called because it's a better match
    // not needing Wrap::operator T&...
    void destroy(Wrap<Third_Party_Lib::X*>) { std::cout << "Mine::destroy()\n"; }
#endif

    struct Q
    {
        Q(Third_Party_Lib::X* p) : p_(p) { }
        ~Q() { destroy(Wrap<Third_Party_Lib::X*>(p_)); }
        Third_Party_Lib::X* p_;
    };
}

#if TEST_MODE    
int main()
{
    Mine::Q q(new Third_Party_Lib::X);
}
#endif

A function pointer would create a way to substitute another implementation. Furthermore, it's transparent to callers (unless they're doing something really stupid like calling sizeof(funcname)).