Opened 12 years ago
Closed 11 years ago
#19941 closed Cleanup/optimization (fixed)
Make running django's test suite easier
Reported by: | Anssi Kääriäinen | Owned by: | nobody |
---|---|---|---|
Component: | Testing framework | Version: | dev |
Severity: | Normal | Keywords: | |
Cc: | timograham@…, Florian Apolloner | Triage Stage: | Accepted |
Has patch: | yes | Needs documentation: | no |
Needs tests: | no | Patch needs improvement: | no |
Easy pickings: | no | UI/UX: | no |
Description
Two suggested changes to tests/runtests.py:
- Automatically use tests/../django as the Django version.
- If no other settings given (either through --settings or DJANGO_SETTINGS_MODULE) then use test_sqlite as settings
Both of the above changes are available from: https://github.com/akaariai/django/compare/test_auto_settings
The first item raises a question: is there some use case where one wants to run tests against *different* django version? To me it seems one wouldn't want to do this, the tests are tied to specific django version.
I can't see any drawback by doing the second item.
Change History (14)
comment:1 by , 12 years ago
Triage Stage: | Unreviewed → Accepted |
---|
comment:2 by , 12 years ago
Triage Stage: | Accepted → Ready for checkin |
---|
LGTM, with the caveat that the long term goal is to get rid of runtests.py, not extend it...
comment:3 by , 12 years ago
Needs documentation: | set |
---|---|
Triage Stage: | Ready for checkin → Accepted |
Not RFC yet in fact :)
comment:6 by , 11 years ago
I'm unsure why import django
is needed? Also the comment in the docstring of upath
references a "try-except of import django" which isn't present.
comment:7 by , 11 years ago
I spotted the import django
and I assumed it was meant as an assert
.
In light of the docstring, maybe the idea was to provide a helpful error message?
comment:8 by , 11 years ago
Resolution: | → fixed |
---|---|
Status: | new → closed |
comment:9 by , 11 years ago
Resolution: | fixed |
---|---|
Status: | closed → new |
Reopening the sys.path.insert call makes the test setup differ from standard installation procedures. We've for a long time tried hard to move away from modifying the sys.path.
As a background, by mangling the sys.path we risk missing import errors that happen when Django is installed with tools like pip. Instead we should promote the use of pip install -e path/to/django
when developing Django.
comment:10 by , 11 years ago
After discussing this a bit more with jezdez in IRC we came to the following conclusion:
pip install -e .
isn't perfect (in the sense that it doesn't mimic a sdist install by 100%) but still better thansys.path
hacks.- drop
sys.path
hacks again. - Update the documentation to note
pip install -e
andPYTHONPATH=..
alternatives. - Output something like
print("Testing against Django installed in '%s'" % django.__file__)
to the console, to allow easier debugging.
comment:11 by , 11 years ago
Cc: | added |
---|
comment:12 by , 11 years ago
Has patch: | unset |
---|---|
Triage Stage: | Ready for checkin → Accepted |
comment:14 by , 11 years ago
Resolution: | → fixed |
---|---|
Status: | new → closed |
I fully agree with 1. and 2. -- I am against supporting other Django versions.