Managing Test Users

See also User Setting Configuration, for details on all project settings to manipulate/change these provided user models.

Provided User Instances

Out of the box, the Django-Expanded-Test-Cases provides four separate users to all tests. These users help to ensure that tests are using a non-empty database. Feel free to change (or ignore) these users as needed to best serve project tests.

To outright disable these auto-generated users, see DJANGO_EXPANDED_TESTCASES_AUTO_GENERATE_USERS

Testing Response Default User Behavior

To outright disable these auto-generated users, see DJANGO_EXPANDED_TESTCASES_REQUEST_USER_STRICTNESS

User Identifiers

By default, these provided users have usernames follows:

  • test_user - The default user, used in all corresponding functionality.

  • test_admin - A provided “is_staff” user, who can see the Django admin.

  • test_superuser - A provided “is_superuser” user, who can see all.

  • test_inactive - A provided “disabled” user.

The test_user object is used as the default for most function calls.

If the DJANGO_EXPANDED_TESTCASES_USER_MODEL_IDENTIFIER setting is set to email, then these usernames will have @example.com appended to the end. For example, test_admin becomes test_admin@example.com.

Furthermore, if these default identifiers aren’t fitting for your project needs, then each user can be configured with a DJANGO_EXPANDED_TESTCASES_DEFAULT_<user>_IDENTIFIER setting.

For more information about customizing test user identifiers, see Configuring Test User Identifiers

Expanding User Authentication Logic

Depending on the project, it’s possible that users will need additional authentication steps above and beyond the standard logic Django provides. Generally, this is reflected in how users are set up in the corresponding UnitTests.

To account for this, Django-Expanded-Test-Cases provides a function that can be overridden for all test case classes that have built-in hook, to allow injecting logic prior to loading a given view:

_get_login_user__extra_user_auth_setup()

A hook function to allow running any additional login/authentication logic that may be required for a given user to access a view.

This function runs towards the end of user authentication, but before actually attempting to log a user in via the Django testing client. By the time this function executes, any built-in/provided user-permission and user-group logic will have already ran.

By default, this function is emtpy, and does nothing other than return the provided user arg.

param user

The current user model that is attempting to log in to access a view.

param user_permissions

Optional permissions to provide to the User before attempting to render the response.

param user_groups

Optional groups to provide to the User, before attempting to render the response.

return

The above user param, with any additional login logic run on it.

Note

Any unhandled args/kwargs passed to a corresponding view function will also pass said args/kwargs inward to this auth hook function.

This is to ensure that any required extra values for processing user authentication can ultimately be accessed for additional user login logic.

Test User Logic

For most logic in Django-Expanded-Test-Cases, a view defaults to manipulating a User object with the username of test_user. This behavior can be changed by providing a different User into the optional kwarg value of each corresponding test call.

Alternatively, if a majority of the project tests check against a single user, consider setting the attributes of the provided test_user model according to project needs.

For example, the below snippet will change the first and last name of this “default” testing user, such that all following UnitTesting logic will see this updated first and last name, unless a separate user is explicitly provided.

// Grab provided ETC default testing user.
my_default_user = self.get_user('test_user')

// Change first and last name to some new value.
my_default_user.first_name = 'UpdatedFirstName'
my_default_user.last_name = 'UpdatedLastName'

// Save model changes, so it persists in the database for the rest of the test.
my_default_user.save()

If something like above is ran somewhere at the start of the inheriting test class, then this logic will propagate to all inner tests. For example, placing the above logic in either the class setUp() , setUpClass() , or setUpTestData() functions.

Warning

If using one of the three above functions, reminder to account for Python’s behavior of super() , to prevent accidentally overriding pre-existing setup logic.