%global _empty_manifest_terminate_build 0 Name: python-django-pytest Version: 0.2.0 Release: 1 Summary: django test runner to use py.test tests License: LICENSE.txt URL: http://github.com/buchuki/django-pytest Source0: https://mirrors.nju.edu.cn/pypi/web/packages/b2/e2/2a87105042c08a6f116aac1d9c666e89982a4f707652a0f7d76e8a88b554/django-pytest-0.2.0.tar.gz BuildArch: noarch %description This project allows you to use py.test as a django test runner, instead of the default test runner. To use it, add it to your python path and add `django_pytest` to your installed apps. Also set the `TEST_RUNNER = 'django_pytest.test_runner.run_tests'` setting. If you're using Django 1.3 or newer set `TEST_RUNNER = 'django_pytest.test_runner.TestRunner'` or Django will print deprecation warnings each time you run your tests. Also create a `conftest.py` in your project directory and include: from django_pytest.conftest import pytest_funcarg__client, pytest_funcarg__django_client You can also use: from django_pytest.auth_funcargs import pytest_funcarg__user, pytest_funcarg__groups to import a user or some groups with users in them Now anywhere in your project, you can create files called `test_.py`. These are standard py.test test files. Use the funcarg `client` in every test to both instantiate a test database that is cleared after each test and to provide you with a django test client object identical to the one used in django's test system. For example: def test_filter(client): response = client.get('/browse/', {'filter': '1'}) assert response.status_code == 200 Use `./manage.py test` to run the py.test test runs (ie: it replaces the standard django test runner). You can pass py.test options to the command and they will be forwarded to py.test. (Technically, I haven't got it passing all options, just the most common ones I use) The management command has been set up so that syncdb will use the django core syncdb if `SOUTH_TESTS_MIGRATE` is set to False, if south is installed. This prevents migrations from running when running unit tests. This speeds up test setup significantly, but it means your test db may not be identical to production, if you have faulty migrations. py.test automatically picks up any subclasses of `unittest.TestCase`, provided they are in a module named `test_.py`. Thus, all your existing django unittests should work seemlessly with py.test, although you may have to rename your test files if they do not conform to this convention. You can also write custom py.test test collection hooks to pick up test modules that are named in a different directory structure. This project differs from in that it provides a django test runner that calls py.test, rather than creating a py.test plugin to test django projects. I believe there is overlapping functionality from the two projects, and also that they can be integrated into a single project, but I have not looked at the feasibility of this yet. %package -n python3-django-pytest Summary: django test runner to use py.test tests Provides: python-django-pytest BuildRequires: python3-devel BuildRequires: python3-setuptools BuildRequires: python3-pip %description -n python3-django-pytest This project allows you to use py.test as a django test runner, instead of the default test runner. To use it, add it to your python path and add `django_pytest` to your installed apps. Also set the `TEST_RUNNER = 'django_pytest.test_runner.run_tests'` setting. If you're using Django 1.3 or newer set `TEST_RUNNER = 'django_pytest.test_runner.TestRunner'` or Django will print deprecation warnings each time you run your tests. Also create a `conftest.py` in your project directory and include: from django_pytest.conftest import pytest_funcarg__client, pytest_funcarg__django_client You can also use: from django_pytest.auth_funcargs import pytest_funcarg__user, pytest_funcarg__groups to import a user or some groups with users in them Now anywhere in your project, you can create files called `test_.py`. These are standard py.test test files. Use the funcarg `client` in every test to both instantiate a test database that is cleared after each test and to provide you with a django test client object identical to the one used in django's test system. For example: def test_filter(client): response = client.get('/browse/', {'filter': '1'}) assert response.status_code == 200 Use `./manage.py test` to run the py.test test runs (ie: it replaces the standard django test runner). You can pass py.test options to the command and they will be forwarded to py.test. (Technically, I haven't got it passing all options, just the most common ones I use) The management command has been set up so that syncdb will use the django core syncdb if `SOUTH_TESTS_MIGRATE` is set to False, if south is installed. This prevents migrations from running when running unit tests. This speeds up test setup significantly, but it means your test db may not be identical to production, if you have faulty migrations. py.test automatically picks up any subclasses of `unittest.TestCase`, provided they are in a module named `test_.py`. Thus, all your existing django unittests should work seemlessly with py.test, although you may have to rename your test files if they do not conform to this convention. You can also write custom py.test test collection hooks to pick up test modules that are named in a different directory structure. This project differs from in that it provides a django test runner that calls py.test, rather than creating a py.test plugin to test django projects. I believe there is overlapping functionality from the two projects, and also that they can be integrated into a single project, but I have not looked at the feasibility of this yet. %package help Summary: Development documents and examples for django-pytest Provides: python3-django-pytest-doc %description help This project allows you to use py.test as a django test runner, instead of the default test runner. To use it, add it to your python path and add `django_pytest` to your installed apps. Also set the `TEST_RUNNER = 'django_pytest.test_runner.run_tests'` setting. If you're using Django 1.3 or newer set `TEST_RUNNER = 'django_pytest.test_runner.TestRunner'` or Django will print deprecation warnings each time you run your tests. Also create a `conftest.py` in your project directory and include: from django_pytest.conftest import pytest_funcarg__client, pytest_funcarg__django_client You can also use: from django_pytest.auth_funcargs import pytest_funcarg__user, pytest_funcarg__groups to import a user or some groups with users in them Now anywhere in your project, you can create files called `test_.py`. These are standard py.test test files. Use the funcarg `client` in every test to both instantiate a test database that is cleared after each test and to provide you with a django test client object identical to the one used in django's test system. For example: def test_filter(client): response = client.get('/browse/', {'filter': '1'}) assert response.status_code == 200 Use `./manage.py test` to run the py.test test runs (ie: it replaces the standard django test runner). You can pass py.test options to the command and they will be forwarded to py.test. (Technically, I haven't got it passing all options, just the most common ones I use) The management command has been set up so that syncdb will use the django core syncdb if `SOUTH_TESTS_MIGRATE` is set to False, if south is installed. This prevents migrations from running when running unit tests. This speeds up test setup significantly, but it means your test db may not be identical to production, if you have faulty migrations. py.test automatically picks up any subclasses of `unittest.TestCase`, provided they are in a module named `test_.py`. Thus, all your existing django unittests should work seemlessly with py.test, although you may have to rename your test files if they do not conform to this convention. You can also write custom py.test test collection hooks to pick up test modules that are named in a different directory structure. This project differs from in that it provides a django test runner that calls py.test, rather than creating a py.test plugin to test django projects. I believe there is overlapping functionality from the two projects, and also that they can be integrated into a single project, but I have not looked at the feasibility of this yet. %prep %autosetup -n django-pytest-0.2.0 %build %py3_build %install %py3_install install -d -m755 %{buildroot}/%{_pkgdocdir} if [ -d doc ]; then cp -arf doc %{buildroot}/%{_pkgdocdir}; fi if [ -d docs ]; then cp -arf docs %{buildroot}/%{_pkgdocdir}; fi if [ -d example ]; then cp -arf example %{buildroot}/%{_pkgdocdir}; fi if [ -d examples ]; then cp -arf examples %{buildroot}/%{_pkgdocdir}; fi pushd %{buildroot} if [ -d usr/lib ]; then find usr/lib -type f -printf "/%h/%f\n" >> filelist.lst fi if [ -d usr/lib64 ]; then find usr/lib64 -type f -printf "/%h/%f\n" >> filelist.lst fi if [ -d usr/bin ]; then find usr/bin -type f -printf "/%h/%f\n" >> filelist.lst fi if [ -d usr/sbin ]; then find usr/sbin -type f -printf "/%h/%f\n" >> filelist.lst fi touch doclist.lst if [ -d usr/share/man ]; then find usr/share/man -type f -printf "/%h/%f.gz\n" >> doclist.lst fi popd mv %{buildroot}/filelist.lst . mv %{buildroot}/doclist.lst . %files -n python3-django-pytest -f filelist.lst %dir %{python3_sitelib}/* %files help -f doclist.lst %{_docdir}/* %changelog * Fri Apr 21 2023 Python_Bot - 0.2.0-1 - Package Spec generated