Pytest-django: admin_user doesn't like django_username_field being set to email

[tolomea]

I'm using https://github.com/tmm/django-username-email which uses the email in place of having a separate user name, this generally works well but it breaks the admin_user fixture because this:

if username_field != 'username':
    extra_fields[username_field] = 'admin'

leads to this

user = UserModel._default_manager.create_superuser(
    'admin', '[email protected]', 'password', **extra_fields)

raising this

TypeError: create_superuser() got multiple values for argument 'email'

[alexdemari]

I have the same problem.

[aalvrz]

Did you find a solution for this?

[tolomea]

I overrode the admin_user fixture in conftest.py, you just declare a function there with the same name. Mine looks like:

@pytest.fixture()
def admin_user(db, django_user_model, django_username_field):
    """A Django admin user.

    This uses an existing user with username 'admin', or creates a new one with
    password 'password'.
    """
    UserModel = django_user_model
    username_field = django_username_field

    try:
        user = UserModel._default_manager.get(**{username_field: '[email protected]'})
    except UserModel.DoesNotExist:
        extra_fields = {}
        user = UserModel._default_manager.create_superuser(
            '[email protected]', 'password', **extra_fields)
    return user

[driesdesmet]

Yeah, I also overwrote it. Easy enough to do. It looks like the authors of pytest-django took the effort of making it work for the case where username=email, but then in practice, this doesn't work.

[blueyed]

The code was changed in this regard: https://github.com/blueyed/pytest-django/blob/33617687f185fecf04bf4bdd99017289078f52df/pytest_django/fixtures.py#L261-L262

Via https://github.com/pytest-dev/pytest-django/commit/a3dc56d895b73738ff81b08c87ea68a0394984e0

So I assume this (or at least the original issue) is fixed?

[driesdesmet]

In my case I actually had an adapted UserModel._default_manager.create_superuser method that does not take a username argument. That's what you tend to do if you have a custom UserModel that does not have a username field (but an email field).

So, your code change is indeed better, but does not cover the case when you have no username field. Which is moot anyway, because you can't cover all custom cases of course. Thanks for the follow up.