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%20in%20django%20tests > > 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.
