innov
/
django1
1
0
Fork 0
Code Issues Pull Requests 1 Projects Releases Wiki Activity

Refs #26089 -- Removed obsolete docs about custom user model testing.

This commit is contained in:
Tim Graham 2016-01-23 09:42:27 -05:00
parent 3b759661a8
commit 1e9150443e
2 changed files with 2 additions and 65 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

4
docs/releases/1.6.txt
View File

@ -454,8 +454,8 @@ Custom User models in tests
The introduction of the new test runner has also slightly changed the way that
test models are imported. As a result, any test that overrides ``AUTH_USER_MODEL``
to test behavior with one of Django's test user models (
:class:`~django.contrib.auth.tests.custom_user.CustomUser` and
:class:`~django.contrib.auth.tests.custom_user.ExtensionUser`) must now
``django.contrib.auth.tests.custom_user.CustomUser`` and
``django.contrib.auth.tests.custom_user.ExtensionUser``) must now
explicitly import the User model in your test module::
from django.contrib.auth.tests.custom_user import CustomUser

63
docs/topics/auth/customizing.txt
View File

@ -896,69 +896,6 @@ If your project uses proxy models, you must either modify the proxy to extend
the User model that is currently in use in your project, or merge your proxy's
behavior into your User subclass.
Custom users and testing/fixtures
---------------------------------
If you are writing an application that interacts with the User model, you must
take some precautions to ensure that your test suite will run regardless of
the User model that is being used by a project. Any test that instantiates an
instance of User will fail if the User model has been swapped out. This
includes any attempt to create an instance of User with a fixture.
To ensure that your test suite will pass in any project configuration,
``django.contrib.auth.tests.utils`` defines a ``@skipIfCustomUser`` decorator.
This decorator will cause a test case to be skipped if any User model other
than the default Django user is in use. This decorator can be applied to a
single test, or to an entire test class.
.. deprecated:: 1.9
With the test discovery changes in Django 1.6, the tests for
``django.contrib`` apps are no longer run as part of the user's project.
Therefore, the ``@skipIfCustomUser`` decorator is no longer needed to
decorate tests in ``django.contrib.auth``.
Depending on your application, tests may also be needed to be added to ensure
that the application works with *any* user model, not just the default User
model. To assist with this, Django provides two substitute user models that
can be used in test suites:
.. class:: tests.custom_user.CustomUser
A custom user model that uses an ``email`` field as the username, and has a basic
admin-compliant permissions setup
.. class:: tests.custom_user.ExtensionUser
A custom user model that extends ``django.contrib.auth.models.AbstractUser``,
adding a ``date_of_birth`` field.
You can then use the ``@override_settings`` decorator to make that test run
with the custom User model. For example, here is a skeleton for a test that
would test three possible User models -- the default, plus the two User
models provided by ``auth`` app::
from django.contrib.auth.tests.utils import skipIfCustomUser
from django.contrib.auth.tests.custom_user import CustomUser, ExtensionUser
from django.test import TestCase, override_settings
class ApplicationTestCase(TestCase):
@skipIfCustomUser
def test_normal_user(self):
"Run tests for the normal user model"
self.assertSomething()
@override_settings(AUTH_USER_MODEL='auth.CustomUser')
def test_custom_user(self):
"Run tests for a custom user model with email-based authentication"
self.assertSomething()
@override_settings(AUTH_USER_MODEL='auth.ExtensionUser')
def test_extension_user(self):
"Run tests for a simple extension of the built-in User."
self.assertSomething()
A full example
--------------