Thanks Russ, that's helpful. I would think signals would ideally be a solution for this, no? E.g., a setup and teardown signal that fired in setup_test_environment() and teardown_test_environment(), respectfully. I was actually hoping to find this already implemented when I checked the documentation for signals.
On Sep 16, 5:13 pm, Russell Keith-Magee <[email protected]> wrote: > On Fri, Sep 17, 2010 at 6:15 AM, Jim D. <[email protected]> wrote: > > I have some code that calls a third-party API in a Django application > > I'm working on, which could be triggered at various points throughout > > a project. I would like to ensure that the API itself doesn't actually > > get called at all during test mode, much the same way that Django > > itself swaps out the email backend during test mode to ensure emails > > don't actually get sent during testing. > > > The key point here is I need to ensure the real library isn't being > > called anywhere during the tests being run throughout the suite, not > > just in the test code I'm writing specifically for the application > > itself. > > > Is there a clean way to do this? I notice that Django disables the > > email and a few other settings in the setup_test_environment() > > function. I'd like to do something similar, but the only idea I've > > come up with so far is to create a custom test runner that extends the > > default setup_test_environment() method and adds a few items of my > > own. While this would work, it would depend on the project using a > > custom test runner. > > > Other ideas include a crazy hack like this guy has proposed: > >http://www.thebitguru.com/blog/view/246-Using%20custom%20settings%20i... > > > Surely others of you have had to ensure a given library isn't called > > during testing or development (e.g. if you were implementing a payment > > processor API, you wouldn't want to actually call that library during > > tests). Am I just missing a totally obvious way to accomplish this? > > A custom test runner would be the usual way to accomplish this, and as > of Django 1.2, it's a lot easier to write one because the test runner > is class based. On a smaller scale, you could also accomplish this > using a setUp()/tearDown() pair in individual test cases. > > The "if TEST" approach advocated by 'thebitguru' will certainly work, > but it's not a pattern that I'd like to see take hold in Django > itself. This approach essentially introduces branches into your main > codebase, so now you need to be testing whether or not your code is > hitting the right branches -- in theory, it is possible that your > production code could activate the "if TEST' branch, so you need to > test that this won't happen. > > If you have a suggestion of a better way to provide setup/teardown > hooks, I'd be happy to hear it. > > Yours, > Russ Magee %-) -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
