pytest-django
pytest-django copied to clipboard
pytest-dev
A Django plugin for pytest.
As proposed in #471, here is an update to `--fail-on-template-vars` that causes missing template variables to be ignored if they use the `default` filter, like `{{ does_not_exist|default:"ok" }}`. This is...
I use both in my tests and I created a media fixture (creating a temporary media directory and using the settings fixture) with autouse=True, due to alphabetic order it made...
pytest-django sets up Django in `pytest_load_initial_conftests` already, which requires you to use a pytest plugin yourself if you want to do anything before it, e.g. changing project settings for tests...
Django `setup_databases` has a `parallel` arg to avoid running migrations for each parallel runner. Migrations are really slow and it was critical to our migration to pytest-django. I had to...
Now when we run our tests with -n4, we get errors that the database already exists.
Hi, I was using django-pytest version 3.3.2 and my tests using Django TestCase were running just fine. Now I started a new project and decided do use the latest django-pytest...
I propose we add a [management command](https://docs.djangoproject.com/en/3.1/howto/custom-management-commands/), maybe something like `python manage.py setup_pytest` which will create a sane `pytest.ini` with some default settings. I intend the generated file to look...
The pytest marker `ignore_template_errors` will deactivate the `InvalidVarException` but the `string_if_invalid` value is still not the default empty string. So it may have some site effects, e.g.: calling manage command...
When upgrading to pytest-django 3.9.0 one of my tests breaks. ```python @pytest.mark.django_db @patch("ntnui.utils.gsuite.GSuite.unsubscribe_from_singular_mailing_list") @patch("ntnui.utils.gsuite.GSuite.unsubscribe_from_board_mailing_list") @patch("ntnui.utils.gsuite.GSuite.unsubscribe_from_group_mailing_list") @pytest.mark.parametrize( ("membership_type", "leave_group_list", "leave_board_list", "leave_singular_list"), [ (MembershipType.member, True, False, False), (MembershipType.board_member, True, True, False), (MembershipType.leader,...
Wouldn't it be reasonable to have a request factory, which sets `user` field by default on every created request? Like `admin_client` does. For example: ```py @fixture def rf_admin(admin_user): from django.test.client...
