Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Create helper fixtures for authenticated states on RequestFactory and client #565

Open
5 tasks done
tony opened this issue Dec 25, 2017 · 0 comments · May be fixed by #568
Open
5 tasks done

Create helper fixtures for authenticated states on RequestFactory and client #565

tony opened this issue Dec 25, 2017 · 0 comments · May be fixed by #568

Comments

@tony
Copy link
Member

tony commented Dec 25, 2017

I think the below are widely enough used on Django projects tests to be part of pytest-django itself.

tony added a commit to develtech/pytest-django that referenced this issue Dec 26, 2017
Fixes pytest-dev#565

This is based on conversations in issues pytest-dev#553, pytest-dev#554, and pytest-dev#284

- Introduces a django_user fixture, which is a user with no additional
  priveleges. Similar to admin_user.
- A user_client, based on django_user. Similar to admin_client.
- 3 new RequestFactory based fixtures, for unauthenticated,
  authenticated, and admin users:

  - rf_unauth: relies on AnonymousUser, similar to django docs
    example.
  - rf_admin: relies on admin_user fixture
  - rf_user: relies on new django_user fixture

  In addition, these 3 fixtures differ from rf in that they:

  - Mimic AuthenticationMiddleware by add the user attribute to
    the request object
  - Mimic SessionMiddleware by adding the 'session' attribute
    to the request object. This is an in-memory session store object
    from ``django.contrib.sessions.backends.base.SessionBase``.

This fills the gaps left over by not having normal and unauthenticated
user objects, clients, and request factories (when admin ones were
available), and also covers a common case likely present in Django
projects - anonymous (not logged in), authenticated, and admin users.
@tony tony linked a pull request Dec 26, 2017 that will close this issue
tony added a commit to develtech/pytest-django that referenced this issue Dec 26, 2017
Fixes pytest-dev#565

This is based on conversations in issues pytest-dev#553, pytest-dev#554, and pytest-dev#284

- Introduces a django_user fixture, which is a user with no additional
  priveleges. Similar to admin_user.
- A user_client, based on django_user. Similar to admin_client.
- 3 new RequestFactory based fixtures, for unauthenticated,
  authenticated, and admin users:

  - rf_unauth: relies on AnonymousUser, similar to django docs
    example.
  - rf_admin: relies on admin_user fixture
  - rf_user: relies on new django_user fixture

  In addition, these 3 fixtures differ from rf in that they:

  - Mimic AuthenticationMiddleware by add the user attribute to
    the request object
  - Mimic SessionMiddleware by adding the 'session' attribute
    to the request object. This is an in-memory session store object
    from ``django.contrib.sessions.backends.base.SessionBase``.

This fills the gaps left over by not having normal and unauthenticated
user objects, clients, and request factories (when admin ones were
available), and also covers a common case likely present in Django
projects - anonymous (not logged in), authenticated, and admin users.
tony added a commit to develtech/pytest-django that referenced this issue Jan 18, 2018
Fixes pytest-dev#565

This is based on conversations in issues pytest-dev#553, pytest-dev#554, and pytest-dev#284

- Introduces a django_user fixture, which is a user with no additional
  priveleges. Similar to admin_user.
- A user_client, based on django_user. Similar to admin_client.
- 3 new RequestFactory based fixtures, for unauthenticated,
  authenticated, and admin users:

  - rf_unauth: relies on AnonymousUser, similar to django docs
    example.
  - rf_admin: relies on admin_user fixture
  - rf_user: relies on new django_user fixture

  In addition, these 3 fixtures differ from rf in that they:

  - Mimic AuthenticationMiddleware by add the user attribute to
    the request object
  - Mimic SessionMiddleware by adding the 'session' attribute
    to the request object. This is an in-memory session store object
    from ``django.contrib.sessions.backends.base.SessionBase``.

This fills the gaps left over by not having normal and unauthenticated
user objects, clients, and request factories (when admin ones were
available), and also covers a common case likely present in Django
projects - anonymous (not logged in), authenticated, and admin users.
tony added a commit to develtech/pytest-django that referenced this issue Jan 18, 2018
Fixes pytest-dev#565

This is based on conversations in issues pytest-dev#553, pytest-dev#554, and pytest-dev#284

- Introduces a django_user fixture, which is a user with no additional
  priveleges. Similar to admin_user.
- A user_client, based on django_user. Similar to admin_client.
- 3 new RequestFactory based fixtures, for unauthenticated,
  authenticated, and admin users:

  - rf_unauth: relies on AnonymousUser, similar to django docs
    example.
  - rf_admin: relies on admin_user fixture
  - rf_user: relies on new django_user fixture

  In addition, these 3 fixtures differ from rf in that they:

  - Mimic AuthenticationMiddleware by add the user attribute to
    the request object
  - Mimic SessionMiddleware by adding the 'session' attribute
    to the request object. This is an in-memory session store object
    from ``django.contrib.sessions.backends.base.SessionBase``.

This fills the gaps left over by not having normal and unauthenticated
user objects, clients, and request factories (when admin ones were
available), and also covers a common case likely present in Django
projects - anonymous (not logged in), authenticated, and admin users.

Also, Update fixtures.py with changes from @blueyed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant