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 provided by the admin app, which is
not installed by default. Russell brought up some points which made
me think about this more. My initial implementation was to force the
inclusion of the admin app if it wasn't already installed, but I agree
with Russell's initial comment that it isn't testing for the presence
of the admin app.
I believe that we should not run these tests if we cannot find the
templates for the same reason we don't run Docutils tests if docutils
is not installed. Though the error reported that the template is not
found is "correct", I don't believe it is a correct test failure
because that is not the goal of the test case.
> 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 provided by the admin app, which is > not installed by default. Russell brought up some points which made > me think about this more. My initial implementation was to force the > inclusion of the admin app if it wasn't already installed, but I agree > with Russell's initial comment that it isn't testing for the presence > of the admin app.
> I believe that we should not run these tests if we cannot find the > templates for the same reason we don't run Docutils tests if docutils > is not installed. Though the error reported that the template is not > found is "correct", I don't believe it is a correct test failure > because that is not the goal of the test case.
I disagree. Like I say in the comment for the ticket, you can't claim that the auth application works correctly in your project if those templates are not available.
The comparison with docutils tests is slightly off target. There is an argument to me made for skipping those tests - but not because we can't find the templates. Failing due to the non-existence of the templates is a legitimate failure if the user is actually using the views.
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.
There could actually be an overlap here with #4788 - that ticket calls for a mechanism to skip and report tests that are known and acceptable failures. Providing a project-level way to skip tests that are known failures could be one solution to both problems.
> 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
the tests? This would negate the use of urls that was introduced in
#7521. The patch you submitted for loading test templates in #7611
seems to complement the use of urls from #7521 in TestCase. I feel it
should be both or none. In the latter case, we should simply skip the
test case if django.contrib.auth.views.password_reset is not used.
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 follow what other tests did and pass the test in the
case where the test is actually skipped.
> > I believe that we should not run these tests if we cannot find the
> > templates for the same reason we don't run Docutils tests if docutils
> > is not installed. Though the error reported that the template is not
> > found is "correct", I don't believe it is a correct test failure
> > because that is not the goal of the test case.
> I disagree. Like I say in the comment for the ticket, you can't claim
> that the auth application works correctly in your project if those
> templates are not available.
Not sure if this should be considered a related issue - the auth tests
use a different urlconf that only include the auth urls, so if you
provide custom registration templates that do reverse lookups with {%
url %} for other urls in your projects, the tests fail...
> 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 templates that do reverse lookups with {%
> url %} for other urls in your projects, the tests fail...
Exactly, I ran into this problem as well. By overriding the urls, all
the other reverse lookups in the template start failing. Maybe reverse
lookups should fail silently while running under a unit tests?
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 ChangePasswordTest, to ensure that the
correct templates are used during the test.
