Opened 13 years ago
Closed 12 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 , 13 years ago
| Triage Stage: | Unreviewed → Accepted |
|---|
comment:2 by , 13 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 , 13 years ago
| Needs documentation: | set |
|---|---|
| Triage Stage: | Ready for checkin → Accepted |
Not RFC yet in fact :)
comment:6 by , 12 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 , 12 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 , 12 years ago
| Resolution: | → fixed |
|---|---|
| Status: | new → closed |
comment:9 by , 12 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 , 12 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.pathhacks.- drop
sys.pathhacks again. - Update the documentation to note
pip install -eandPYTHONPATH=..alternatives. - Output something like
print("Testing against Django installed in '%s'" % django.__file__)to the console, to allow easier debugging.
comment:11 by , 12 years ago
| Cc: | added |
|---|
comment:12 by , 12 years ago
| Has patch: | unset |
|---|---|
| Triage Stage: | Ready for checkin → Accepted |
comment:14 by , 12 years ago
| Resolution: | → fixed |
|---|---|
| Status: | new → closed |
I fully agree with 1. and 2. -- I am against supporting other Django versions.