Not intending to derail the test-skip angle (which sounds generally
useful), but in this case, wouldn't a better fix be to eliminate the
dependency on admin, by providing the needed templates in the auth
test suite itself? PasswordResetTest could also duplicate the setup/
teardown methods used by
On Sep 7, 6:32 am, sciyoshi <[EMAIL PROTECTED]> wrote:
> On Jul 19, 2:15 am, "Russell Keith-Magee" <[EMAIL PROTECTED]>
> wrote:
>
> Not sure if this should be considered a related issue - theauthtests
> use a different urlconf that only include theauthurls, so if you
> provide custom registration
On Jul 19, 2:15 am, "Russell Keith-Magee" <[EMAIL PROTECTED]>
wrote:
> On Sat, Jul 19, 2008 at 1:58 PM, Jason Yan <[EMAIL PROTECTED]> wrote:
>
> > Re:http://code.djangoproject.com/ticket/7611
>
> > I believe that we should not run these tests if we cannot find the
> > templates for the same reason
On Sat, Jul 19, 2008 at 1:58 PM, Jason Yan <[EMAIL PROTECTED]> wrote:
>
> Re: http://code.djangoproject.com/ticket/7611
>
> The current situation is that if you create a new Django project and
> run the unit tests, the contrib.auth baisc tests fail due to missing
> templates. These templates are
> However, if the user is _not_ using the views (e.g., they're using the
> auth.User model, but providing their own login views), there is an
> argument to be made for skipping the tests.
Is it safe to say that if we try to
reverse('django.contrib.auth.views.password_reset'), we should not run
th
I attached a new patch to the ticket in the original post. The hard-
coded URL felt like it went against your reasoning for testing the
auth application in your own project, so hopefully this approach gives
us the best of both worlds. Without a proper way to skip test cases
yet, I decided to fol
