Django

Code

Ticket #7521 (closed: fixed)

Opened 2 years ago

Last modified 11 months ago

auth/tests fail on custom project with "manage.py test"

Reported by: anonymous Assigned to: telenieko
Milestone: 1.0 Component: Testing framework
Version: 1.1-beta-1 Keywords: test failure
Cc: Triage Stage: Accepted
Has patch: 1 Needs documentation: 0
Needs tests: 0 Patch needs improvement: 0

Description

The auth/tests.py, which evidently was added yesterday, produces some failed assertions when enacted by 'python manage.py test': 

======================================================================
FAIL: test_email_found (django.contrib.auth.tests.PasswordResetTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/site-packages/django/contrib/auth/tests.py", line 71, in test_email_found
    self.assertEquals(response.status_code, 302)
AssertionError: 404 != 302

======================================================================
FAIL: test_email_not_found (django.contrib.auth.tests.PasswordResetTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/site-packages/django/contrib/auth/tests.py", line 64, in test_email_not_found
    self.assertEquals(response.status_code, 200)
AssertionError: 404 != 200

----------------------------------------------------------------------

Attachments

7521.diff (6.0 kB) - added by telenieko on 06/26/08 06:57:19.
Patch to allow "urls" parameter on tests.

Change History

06/22/08 00:54:38 changed by russellm

  • status changed from new to closed.
  • needs_better_patch changed.
  • resolution set to worksforme.
  • needs_tests changed.
  • needs_docs changed.

I'm not seeing this failure and the buildbot agrees. As at [7722], there is a failure in the tests, but it is in a different test to the one you are reporting.

06/22/08 05:53:26 changed by telenieko

  • status changed from closed to reopened.
  • resolution deleted.
  • stage changed from Unreviewed to Accepted.
  • component changed from Authentication to Unit test system.
  • milestone set to 1.0 alpha.

Not exacly, If you run "./manage.py test" on a project which has contrib.auth in INSTALLED_APPS, django will run the contrib.auth tests, and the urls.py required by those tests is not included in this case (the needed urls.py will only be included if you are running with runtests.py)

So anybody using the test framework on his project, whith contrib.auth installed is likely to have problems.

An option would be the TestCase? of contrib.auth to add the needed URL's on setUp().

06/22/08 05:53:58 changed by telenieko

  • summary changed from auth/tests fails to auth/tests fail on custom project with "manage.py test".

06/23/08 07:17:58 changed by russellm

  • status changed from reopened to closed.
  • resolution set to fixed.

(In [7726]) Fixed #7521 -- Reverted [7716]. Fixed URLs in test case broke any application that deployed contrib.auth.

06/23/08 15:39:19 changed by dek <dan.kelley@dal.ca>

I'm not sure if it's ok for me to add a comment to a closed issue, but I just wanted to say, as the original reporter, that

1) this works for me now

2) thanks very much for the quick bug fix

Dan.

06/24/08 12:07:35 changed by telenieko

  • status changed from closed to reopened.
  • resolution deleted.
  • stage changed from Accepted to Design decision needed.

I don't think we should consider this fixed, the bug here is that Contrib applications cannot test their on views, because there's no guarantee that user project's will include the contrib app urls. Which will then make those tests fails (that's what happened after [7716] with contrib.auth).

And it seems reasonable that contrib apps should be able to, somehow, test their views when using runtests.py

I can think about two options right now:

  • manage.py test should not run test for contrib apps, they're already tested by runtests.py by django developers.
  • manage.py tests should, somehow, make sure the needed urls are there or disable the tests that would fail otherwise.

I'd really be on option 1, I don't see the point on running tests for contrib apps from the user project when those apps, in theory, have already been tested.

I'll post this to django-developers, and mark as DDN. Just commenting there to leave track.

06/25/08 18:04:08 changed by telenieko

  • owner set to telenieko.
  • status changed from reopened to new.
  • stage changed from Design decision needed to Accepted.

Brought for discussion here seems to be consensus on providing a way for TestCases? to orverride the root urlconf on setup and bring the original urlconf back on teardown.

Apparently formtools already do this.

06/26/08 06:57:19 changed by telenieko

  • attachment 7521.diff added.

Patch to allow "urls" parameter on tests.

06/26/08 07:00:12 changed by telenieko

  • has_patch set to 1.

Attached a patch which allows a "urls" parameter on TestCase?, some other things were added:

  • Added clear_url_caches() to django.core.urlresolvers (We need to clear the cache when changing URLconfs)
  • Changed formtools.tests to use the new "urls" parameter instead of it's own hack (which could break for the cache).
  • Added two TestCase? to check this works, and documentation.

Note that [7716] should be brought back after this gets in, with a new urls parameter.

NOTE: Also available on git: gitweb, git

06/27/08 04:44:29 changed by telenieko

The diff for getting back [7716] using the urls parameter is here. I'll attach if needed.

06/27/08 10:00:12 changed by garcia_marc

  • milestone changed from 1.0 alpha to 1.0.

According to ticket organization defined in http://code.djangoproject.com/wiki/VersionOneRoadmap#how-you-can-help 1.0 alpha tickets should be just features in the Must have (http://code.djangoproject.com/wiki/VersionOneRoadmap#must-have-features) list.

As bug, it should be fixed before 1.0 milestone.

06/30/08 07:34:29 changed by russellm

  • status changed from new to closed.
  • resolution set to fixed.

(In [7805]) Fixed #7521 -- Added the ability to customize ROOT_URLCONF for the duration of a TestCase?. Thanks to Mark Fargas (telenieko) for his work on this patch.

06/30/08 08:11:13 changed by russellm

(In [7808]) Refs #7521 -- Re-reverted [7716] (originally reverted in [7726]), now modified to use the new TestCase? urlpattern framework.

10/31/08 20:55:38 changed by siddhi

There is still a problem here. I have the auth app installed, but I've customised the templates. It so happens that the template has a reverse lookup to some urls defined in my ROOT_URLCONF. Because the unit test case overrides my urls, the reverse lookup fails and the template rendering also fails (raises a NoReverseMatch? exception) and the unit test fails.

04/28/09 12:05:05 changed by fnl

  • status changed from closed to reopened.
  • version changed from SVN to 1.1-beta-1.
  • resolution deleted.

Having the same problems as siddhi. Why are the authentication tests there at all, especially, things like self.assert_("Please enter your new password" in response.content) should not be part of the base django dango distribution, at least not in the beta or stable - I'm having problems to test my apps with (1, 1, 0, 'beta', 1) because I always have to first remove the useless tests and replace them with something that works for me.

04/28/09 12:18:17 changed by mtredinnick

  • status changed from reopened to closed.
  • resolution set to fixed.

comment:13 seems to be reporting a version of #8404. This ticket has already been resolved. If there is a new problem that is not the same as #8404 (or some other existing ticket), please open a new ticket so that the problem tracking history is straight. Realise that "I do not think the tests for an application I have installed should be run at all" is not a bug report (comment:14). Improvements welcome; suggestions to now test things, not so much. Reclosing.

04/29/09 04:28:50 changed by fnl

Ok, sorry for adding this into the wrong ticket - moved this issue to #8404, as it fits quite well with that description. I think tests that force you to use the English language and an overly specific implementation schema should not be part of the Django base distribution (see my comments there) - however, I am not trying to say "do not run tests for installed apps" as suggested by comment:15, what I am arguing is that in the base distribution there must be a sensible amount of freedom of choice for the implementation, e.g. language and phrase usage restrictions made through tests provided by the base distribution are misplaced.

Add/Change #7521 (auth/tests fail on custom project with "manage.py test")




Change Properties
Action