Auth Handling Configuration *************************** The following `Django settings `_ allow configuration of the **ExpandedTestCases** package, regarding User and Auth settings. All of these settings are optional, and will fall back to a default value if not defined. .. Note:: By default, **ExpandedTestCases** will always generate 4 default test users. One super user, one admin user, one deactivated User, and one standard user. Most settings on this page change properties for generation and handling of these users. Some of these settings also change general user handling during test runtime. Configuring Test Users ====================== AUTO_GENERATE_USERS ------------------- By default, **ExpandedTestCases** provides default testing users. If this is not desired, this setting can be set to False to disable said functionality. If test users are disabled, then most other settings on this page will have no effect either. :Type: ``bool`` :Default: ``True`` **Example:** .. code:: DJANGO_EXPANDED_TESTCASES_AUTO_GENERATE_USERS = False REQUEST_USER_STRICTNESS ----------------------- This setting configures :doc:`Response Assertions<../test_cases/integration_test_case/response_assertions>`, when no user value is explicitly passed in. To match with Django's default behavior, these assertions will default to using an `Anonymous User `_ in any page requests, when no user is passed in. Alternatively, this setting can be set to ``relaxed`` or ``strict`` to change this behavior. The ``relaxed`` mode will auto-provide the "standard user" instance, if a user instance is not explicitly passed in. Meanwhile, the ``strict`` mode requires that any response test either have the ``auto_login`` arg set to False, or that a user instance explicitly be provided. If one of these two criteria are not met, then the assertion will raise a ``ValidationError``. .. note:: When the above description mentions "providing a user instance", the ETC package can accept this in one of two ways. First, each IntegrationTest :doc:`Response Assertion<../test_cases/integration_test_case/response_assertions>` has a ``user`` arg. This is the most direct way to pass in a user, on a per-assertion basis. Alternatively, if you find yourself having multiple response assertions in a row that all use the same user, you can set the class variable ``self.user``. All tests that follow afterwards will fall back to this ``self.user`` variable, if no user is provided as an arg. :Type: ``string`` :Default: ``anonymous`` :Options: [``anonymous``, ``relaxed``, ``strict``] **Example:** .. code:: DJANGO_EXPANDED_TESTCASES_REQUEST_USER_STRICTNESS = 'strict' Configuring Test User Identifiers ================================= The following settings allow specifying what field is used as the User model's "identifier", as well as what value each user is populated with. USER_MODEL_IDENTIFIER --------------------- By default, this package assumes a project uses the ``username`` field on a user as the primary identifier. This setting allows specifying a different identifier field. To do so, provide the literal model field name intended to use. :Type: ``string`` :Default: ``username`` **Example:** .. code:: DJANGO_EXPANDED_TESTCASES_USER_MODEL_IDENTIFIER = 'email' DEFAULT_SUPER_USER_IDENTIFIER ----------------------------- By default, this package will generate a test superuser model identified by either ``super_user``, or ``super_user@example.com``. (Which one is selected depends on the above ``USER_MODEL_IDENTIFIER`` value). Alternatively, specify a custom identifier here. :Type: ``string`` :Default: ``test_superuser`` or ``test_superuser@example.com``, depending on above USER_MODEL_IDENTIFIER setting. **Example:** .. code:: DJANGO_EXPANDED_TESTCASES_DEFAULT_SUPER_USER_IDENTIFIER = 'my_really_cool_value' DEFAULT_ADMIN_USER_IDENTIFIER ----------------------------- By default, this package will generate a test admin user model identified by either ``test_admin``, or ``test_admin@example.com``. (Which one is selected depends on the above ``USER_MODEL_IDENTIFIER`` value). Alternatively, specify a custom identifier here. :Type: ``string`` :Default: ``test_admin`` or ``test_admin@example.com``, depending on above USER_MODEL_IDENTIFIER setting. **Example:** .. code:: DJANGO_EXPANDED_TESTCASES_DEFAULT_ADMIN_USER_IDENTIFIER = 'my_really_cool_value' DEFAULT_STANDARD_USER_IDENTIFIER -------------------------------- By default, this package will generate a test standard user model identified by either ``test_user``, or ``test_user@example.com``. (Which one is selected depends on the above ``USER_MODEL_IDENTIFIER`` value). Alternatively, specify a custom identifier here. :Type: ``string`` :Default: ``test_user`` or ``test_user@example.com``, depending on above USER_MODEL_IDENTIFIER setting. **Example:** .. code:: DJANGO_EXPANDED_TESTCASES_DEFAULT_STANDARD_USER_IDENTIFIER = 'my_really_cool_value' DEFAULT_INACTIVE_USER_IDENTIFIER -------------------------------- By default, this package will generate a test standard user model identified by either ``test_inactive``, or ``test_inactive@example.com``. (Which one is selected depends on the above ``USER_MODEL_IDENTIFIER`` value). Alternatively, specify a custom identifier here. :Type: ``string`` :Default: ``test_inactive`` or ``test_inactive@example.com``, depending on above USER_MODEL_IDENTIFIER setting. **Example:** .. code:: DJANGO_EXPANDED_TESTCASES_DEFAULT_INACTIVE_USER_IDENTIFIER = 'my_really_cool_value' Other Test User Configurations ============================== DJANGO_EXPANDED_TESTCASES_DEFAULT_PASSWORD ------------------------------------------ When generating any test user, **ExpanedTestCases** will provide a default password if none is provided. This password can be changed here. :Type: ``string`` :Default: ``password`` **Example:** .. code:: DJANGO_EXPANDED_TESTCASES_DEFAULT_PASSWORD = 'my_new_password' DJANGO_EXPANDED_TESTCASES_GENERATE_USERS_WITH_REAL_NAMES -------------------------------------------------------- When generating four provided test users, this package will also attempt to generate name values. By default, the super user attempts to generate with ``SuperUserFirst`` as the first_name field and ``SuperUserLast`` as the last_name field. For more normalized names, set this to true. For example, this will change the super user to generate with the name ``John Doe``, instead of ``SuperUserFirst SuperUserLast``. :Type: ``bool`` :Default: ``False`` **Example:** .. code:: DJANGO_EXPANDED_TESTCASES_GENERATE_USERS_WITH_REAL_NAMES = True