Disabling middleware for tests
846 views
Skip to first unread message
davenaff
Jan 22, 2009, 6:17:38 PM1/22/09
to Django users
What is the best way to disable a specific middleware when running
django tests?
This ticket was designated wontfix, so I get test failures on the auth
tests every time I run our test suite:
http://code.djangoproject.com/ticket/9172#comment:12
I'd prefer not to have to edit settings.py every time I run our tests,
and of course I don't like tests that fail...
django tests?
This ticket was designated wontfix, so I get test failures on the auth
tests every time I run our test suite:
http://code.djangoproject.com/ticket/9172#comment:12
I'd prefer not to have to edit settings.py every time I run our tests,
and of course I don't like tests that fail...
Malcolm Tredinnick
Jan 22, 2009, 7:50:05 PM1/22/09
to django...@googlegroups.com
Create a settings file for your testing purposes. It imports your
standard settings file and then modifies any settings that are specific
for the tests (e.g. altering the MIDDLEWARE_CLASSES tuple).
Regards,
Malcolm
davenaff
Jan 26, 2009, 1:16:13 PM1/26/09
to Django users
Malcolm,
Thanks a lot for the pointer. For anyone else interested, here is
what my settings-test.py looks like:
from settings import *
# CSRF Middleware breaks auth tests
MIDDLEWARE_CLASSES = list(MIDDLEWARE_CLASSES)
MIDDLEWARE_CLASSES.remove
('django.contrib.csrf.middleware.CsrfMiddleware')
# Turn this off to allow tests that look at http status to pass
PREPEND_WWW = False
I then run the test suite using this command:
python manage.py test --settings=mysite.settings-test.py
Best,
Dave
On Jan 22, 4:50 pm, Malcolm Tredinnick <malc...@pointy-stick.com>
wrote:
Thanks a lot for the pointer. For anyone else interested, here is
what my settings-test.py looks like:
from settings import *
# CSRF Middleware breaks auth tests
MIDDLEWARE_CLASSES = list(MIDDLEWARE_CLASSES)
MIDDLEWARE_CLASSES.remove
('django.contrib.csrf.middleware.CsrfMiddleware')
# Turn this off to allow tests that look at http status to pass
PREPEND_WWW = False
I then run the test suite using this command:
python manage.py test --settings=mysite.settings-test.py
Best,
Dave
On Jan 22, 4:50 pm, Malcolm Tredinnick <malc...@pointy-stick.com>
wrote:
stryderjzw
Feb 16, 2009, 3:33:05 PM2/16/09
to Django users
This doesn't seem to be working for me.
I created my own test_settings.py in the project root directory.
I ran
python manage.py test --settings=test_settings
It runs as usual and CSRF still fails when I run tests.
Anyone know what I might be doing wrong here? How can I tell that
python manage.py has accepted my test_settings?
On Jan 26, 10:16 am, davenaff <daven...@gmail.com> wrote:
> Malcolm,
>
> Thanks a lot for the pointer. For anyone else interested, here is
> what my settings-test.py looks like:
>
> from settings import *
>
> #CSRFMiddleware breaks authtests
> MIDDLEWARE_CLASSES = list(MIDDLEWARE_CLASSES)
> MIDDLEWARE_CLASSES.remove
> ('django.contrib.csrf.middleware.CsrfMiddleware')
>
> # Turn this off to allowteststhat look at http status to pass
>
> > Regards,
> > Malcolm
I created my own test_settings.py in the project root directory.
I ran
python manage.py test --settings=test_settings
It runs as usual and CSRF still fails when I run tests.
Anyone know what I might be doing wrong here? How can I tell that
python manage.py has accepted my test_settings?
On Jan 26, 10:16 am, davenaff <daven...@gmail.com> wrote:
> Malcolm,
>
> Thanks a lot for the pointer. For anyone else interested, here is
> what my settings-test.py looks like:
>
> from settings import *
>
> #CSRFMiddleware breaks authtests
> MIDDLEWARE_CLASSES = list(MIDDLEWARE_CLASSES)
> MIDDLEWARE_CLASSES.remove
> ('django.contrib.csrf.middleware.CsrfMiddleware')
>
> PREPEND_WWW = False
>
> I then run the test suite using this command:
> python manage.py test --settings=mysite.settings-test.py
>
> Best,
> Dave
>
> On Jan 22, 4:50 pm, Malcolm Tredinnick <malc...@pointy-stick.com>
> wrote:
>
> > On Thu, 2009-01-22 at 15:17 -0800,davenaffwrote:
> > > What is the best way to disable a specific middleware when running
> > > djangotests?
>
> > > This ticket was designated wontfix, so I get test failures on the auth
> > >testsevery time I run our test suite:
>
> I then run the test suite using this command:
> python manage.py test --settings=mysite.settings-test.py
>
> Best,
> Dave
>
> On Jan 22, 4:50 pm, Malcolm Tredinnick <malc...@pointy-stick.com>
> wrote:
>
> > On Thu, 2009-01-22 at 15:17 -0800,davenaffwrote:
> > > What is the best way to disable a specific middleware when running
> > > djangotests?
>
> > > This ticket was designated wontfix, so I get test failures on the auth
> > >http://code.djangoproject.com/ticket/9172#comment:12
>
> > > I'd prefer not to have to edit settings.py every time I run ourtests,
> > > and of course I don't liketeststhat fail...
>
> > > I'd prefer not to have to edit settings.py every time I run ourtests,
>
> > Create a settings file for your testing purposes. It imports your
> > standard settings file and then modifies any settings that are specific
> > for thetests(e.g. altering the MIDDLEWARE_CLASSES tuple).
> > Create a settings file for your testing purposes. It imports your
> > standard settings file and then modifies any settings that are specific
>
> > Regards,
> > Malcolm
felix
Feb 16, 2009, 7:12:27 PM2/16/09
to django...@googlegroups.com
ah ha.
yes, I've wasted several hours over this issue. it took me a while to figure out that it was the CSRF middleware that was breaking the tests. both auth tests and actually every single one that tests the posting of forms.
I didn't see it mention of this issue in either the CSRF docs or the unit test docs, but those are both places that we would first look to diagnose. a docs request ticket should be filed. I couldn't find one existing.
I thought it was something to do with self.client.login failing (because I would get 403)
I couldn't figure this out: is there a way to tell that we are running as a test ?
sorry, I don't get this. what fails ? response.status_code == 200 ?
yes, I've wasted several hours over this issue. it took me a while to figure out that it was the CSRF middleware that was breaking the tests. both auth tests and actually every single one that tests the posting of forms.
I didn't see it mention of this issue in either the CSRF docs or the unit test docs, but those are both places that we would first look to diagnose. a docs request ticket should be filed. I couldn't find one existing.
I thought it was something to do with self.client.login failing (because I would get 403)
I couldn't figure this out: is there a way to tell that we are running as a test ?
felix : crucial-systems.com
On Mon, Feb 16, 2009 at 9:33 PM, stryderjzw <stryd...@gmail.com> wrote:
> # Turn this off to allowteststhat look at http status to pass
> from settings import *
>
> #CSRFMiddleware breaks authtests
> MIDDLEWARE_CLASSES = list(MIDDLEWARE_CLASSES)
> MIDDLEWARE_CLASSES.remove
> ('django.contrib.csrf.middleware.CsrfMiddleware')
>
> PREPEND_WWW = False
sorry, I don't get this. what fails ? response.status_code == 200 ?
stryderjzw
Feb 16, 2009, 9:36:17 PM2/16/09
to Django users
Well, looking at Ticket 9172 (http://code.djangoproject.com/ticket/
9172), we're supposed to be turning off the CSRF middleware during
tests.
I believe we can do that by writing another settings file, disabling
the Csrf Middleware and using that settings file to run our tests, as
per this thread.
However, I'm running into the problem that I have no clue if manage.py
ever read my settings file correctly. I'm assuming it didn't because I
still get the Cross Site Request Forgery error. I can import my
test_settings fine in the shell, so it's not the file that is
incorrect.
I'll dig into this more tonight.
Cheers,
Justin
On Feb 16, 4:12 pm, felix <crucialfe...@gmail.com> wrote:
> ah ha.
>
> yes, I've wasted several hours over this issue. it took me a while to
> figure out that it was the CSRF middleware that was breaking the tests.
> both auth tests and actually every single one that tests the posting of
> forms.
>
> I didn't see it mention of this issue in either the CSRF docs or the unit
> test docs, but those are both places that we would first look to diagnose.
> a docs request ticket should be filed. I couldn't find one existing.
>
> I thought it was something to do with self.client.login failing (because I
> would get 403)
>
> I couldn't figure this out: is there a way to tell that we are running as a
> test ?
>
> felix : crucial-systems.com
9172), we're supposed to be turning off the CSRF middleware during
tests.
I believe we can do that by writing another settings file, disabling
the Csrf Middleware and using that settings file to run our tests, as
per this thread.
However, I'm running into the problem that I have no clue if manage.py
ever read my settings file correctly. I'm assuming it didn't because I
still get the Cross Site Request Forgery error. I can import my
test_settings fine in the shell, so it's not the file that is
incorrect.
I'll dig into this more tonight.
Cheers,
Justin
On Feb 16, 4:12 pm, felix <crucialfe...@gmail.com> wrote:
> ah ha.
>
> yes, I've wasted several hours over this issue. it took me a while to
> figure out that it was the CSRF middleware that was breaking the tests.
> both auth tests and actually every single one that tests the posting of
> forms.
>
> I didn't see it mention of this issue in either the CSRF docs or the unit
> test docs, but those are both places that we would first look to diagnose.
> a docs request ticket should be filed. I couldn't find one existing.
>
> I thought it was something to do with self.client.login failing (because I
> would get 403)
>
> I couldn't figure this out: is there a way to tell that we are running as a
> test ?
>
Malcolm Tredinnick
Feb 16, 2009, 9:42:47 PM2/16/09
to django...@googlegroups.com
On Mon, 2009-02-16 at 18:36 -0800, stryderjzw wrote:
[...]
> However, I'm running into the problem that I have no clue if manage.py
> ever read my settings file correctly.
[...]
> However, I'm running into the problem that I have no clue if manage.py
> ever read my settings file correctly.
The settings file is executable (well, importable) Python code, so put a
print statement in there that will display something when the file is
imported. You could do something like printing the value of
MIDDLEWARE_CLASSES.
Regards,
Malcolm
stryderjzw
Feb 17, 2009, 2:17:57 AM2/17/09
to Django users
Ah yeah, of course I can put a print statement. Thanks Malcolm. Your
many posts have helped me greatly in the past.
Looks like it works with a new Django project. I am using Pinax and
they alter the manage.py file slightly.
Can't see why it's not working though. I guess I'll have to dig in
deeper into the Django code.
On Feb 16, 6:42 pm, Malcolm Tredinnick <malc...@pointy-stick.com>
wrote:
many posts have helped me greatly in the past.
Looks like it works with a new Django project. I am using Pinax and
they alter the manage.py file slightly.
Can't see why it's not working though. I guess I'll have to dig in
deeper into the Django code.
On Feb 16, 6:42 pm, Malcolm Tredinnick <malc...@pointy-stick.com>
wrote:
Reply all
Reply to author
Forward
0 new messages