Django testably setting a client library based on test/prod/dev context

I'm making calls to a particular CRM (Streak) from our backend when new user objects are created. Since new user objects are created en masse during tests, right now, our CRM gets populated with new dummy users. It's a minor pain I'd like to resolve.

Here's my prod Streak client:

class StreakClient(object):
    # bunch of stuff here
    def setup_client(self, client):
        #production API integration code here
        return response['boxKey']

Here's what I'd like:

1. Tests to not actually make production calls.
2. Counter-example: Tests for that client class itself. I have a TestStreakClient test case that needs to work with production Streak.
3. There are a number of assorted tests already in action that call the production code path by default right now. Although I could do so if it's a good long-term practice, I'd rather not have to go back and add a bunch of setUp methods.

My question is:

How should I allow the StreakClient and DummyStreakClient classes to be defined such that the above are possible?

I looked at the post office's mail.py and they seem to dynamically import a module based on a string in the settings file:

def get_mailbox(self)
    klass = import_string(settings.MAIL_BACKEND)
    return klass()

But this strikes me as being a little weird... unless it isn't. I can certainly create a new dummy Streak client and have it loaded in somehow. I could unittest / mock. Maybe something else?

Something else to note - no code really cares about the return value of setup_client. So I don't really need to go down the full intercept-calls-and-mock route here - the crm object creation succeeds or fails silently as per requirements.