Re: Preventing code from running during user tests

[Jim D.]

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 
wrote:
> On Fri, Sep 17, 2010 at 6:15 AM, Jim D.  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 django-us...@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

Re: Preventing code from running during user tests

[Russell Keith-Magee]

On Fri, Sep 17, 2010 at 6:15 AM, Jim D.  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 django-us...@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

Preventing code from running during user tests

[Jim D.]

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?

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-us...@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.