1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
|
%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_<something>.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_<something>.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 <http://github.com/bfirsh/pytest_django> 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_<something>.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_<something>.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 <http://github.com/bfirsh/pytest_django> 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_<something>.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_<something>.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 <http://github.com/bfirsh/pytest_django> 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 07 2023 Python_Bot <Python_Bot@openeuler.org> - 0.2.0-1
- Package Spec generated
|
