Opened 15 years ago
Last modified 6 months ago
#11593 assigned New feature
Incomplete support for app-level testing
Reported by: | Masklinn | Owned by: | Raphael Kimmig |
---|---|---|---|
Component: | Testing framework | Version: | dev |
Severity: | Normal | Keywords: | |
Cc: | Triage Stage: | Accepted | |
Has patch: | yes | Needs documentation: | no |
Needs tests: | no | Patch needs improvement: | yes |
Easy pickings: | no | UI/UX: | no |
Description
Django and its community have a pretty strong focus on the concept of reusable applications: applications as pluggable behavior blocks, independent from one another and from projects. And the test framework documentation and setup emphasize that: the documentation page is called Testing Django applications and the test themselves are saved at the application level not at the project level.
Yet Django provides no provision whatsoever for running tests from an application: a project (or at least a settings and a urls file) is required, and barring fairly weird setups (global settings and urls modules) there is no way to create a new app, write a test and run it just like that. Which means applications aren't as self-contained as they could be, and can't easily be tested "in a void" (independently of everything else).
Change History (22)
follow-up: 2 comment:1 by , 15 years ago
Triage Stage: | Unreviewed → Accepted |
---|
follow-up: 4 comment:2 by , 15 years ago
Replying to russellm:
I concur 100%. The distinction between integration testing of new apps, and system testing of a specific app is a persistent problem, and the cause of more than one ticket in the Django system (e.g., #10976, #10755, and others). This is a problem for which we should have a solid answer.
Can I make a wish while we are on the topic? ;) Django allows me to write test suites (unittest.TestSuite
objects) but won't allow me to run them. Adding one more level of granularity would help users to run any of Application/Test Suite/Test Class/Test Method tests. This would also make django's test running mechanism more similar to unittest's.
If you think this should be a separate ticket I can add one.
comment:3 by , 15 years ago
Cc: | added |
---|
follow-up: 5 comment:4 by , 15 years ago
Replying to Manoj Govindan <egmanoj@gmail.com>:
Replying to russellm:
Can I make a wish while we are on the topic? ;) Django allows me to write test suites (unittest.TestSuite
objects) but won't allow me to run them. Adding one more level of granularity would help users to run any of Application/Test Suite/Test Class/Test Method tests. This would also make django's test running mechanism more similar to unittest's.
What you are proposing isn't a stylistic thing or a particular way that the original proposal could be interpreted - it's a completely new idea. If you have a separate feature request, open a separate ticket.
comment:5 by , 15 years ago
What you are proposing isn't a stylistic thing or a particular way that the original proposal could be interpreted - it's a completely new idea. If you have a separate feature request, open a separate ticket.
comment:6 by , 14 years ago
Severity: | → Normal |
---|---|
Type: | → New feature |
comment:9 by , 6 years ago
Owner: | changed from | to
---|---|
Status: | new → assigned |
This ticket is really old, but I'd still love to see some progress here.
I've been thinking about this a bit lately and below are my thoughts so far.
We probably don't need to write a lot of code here, but rather add some
documentation to the advanced tutorial as well as the advanced testing
documentation.
From what I can see there are a few common things that should be documented.
- How to run tests in a stand alone application (this requires settings).
- How to manage settings for running tests in a stand alone application.
- How to set up views/urls/middleware ... for tests.
- How to add models specifically for tests inside applications.
For 1, 2 and 3. there are several solutions, to get started I'd probably describe
how to use django-admin test
to run the tests with a custom test_settings.py
file.
For 4. there is a simple solution if the app doesn't provide any models itself.
In that case one can simply disable migrations for the app in the test settings.
Ideally I'd like to try implementing a @test_model
decorator as suggested in
https://code.djangoproject.com/ticket/7835 which would also solve the general
case.
I'd love to have the documentation for reusable apps contain (directly, or via links
to the testing docs) all the information required to not only create an app, but also
make sure it has working tests.
I'll try to expand the relevant docs over the next few days. If anyone has some
input on the matter I'd be glad to hear it.
Did I miss any obvious work in that area? Maybe even somewhere in the documentation?
Do you have any suggestions on how specific aspects should be solved?
/e
After looking some more I've found the section in the advanced testing docs that covers
most of this already :-)
I think the one thing that is really missing is some mention of that in the reusable apps introduction.
Also the part in advanced testing that covers how to use models only for tests could probably be worded
a bit more clearly.
comment:10 by , 6 years ago
I've added documentation to the resuable apps intro. PR
One possible way to improve this would be to add a --reusable
flag to the test
management command so that one could run the tests with django-admin test --reusable
or something along those lines instead of copy & pasting a runtests.py
file. Any thoughts?
comment:11 by , 6 years ago
Has patch: | set |
---|
comment:12 by , 6 years ago
Is there a reason why python -m django test --settings=tests.settings tests
(given tests.test_settings
is renamed to settings
) wouldn't work?
That's the pattern I use for all the third party apps I maintain and it seems to be working just fine.
e.g.
- https://github.com/charettes/django-seal/blob/36dde326783d51d1f45348fcb18cfd1418e93881/tox.ini#L20
- https://github.com/charettes/django-seal/tree/36dde326783d51d1f45348fcb18cfd1418e93881/tests
I'm not sure I'm following why a --reusable
flag is required.
comment:13 by , 6 years ago
No good reason at all, that looks much nicer actually :-)
I'll update the PR and I'll change the advanced testing part about reusable applications as well,
unless you see a good reason to suggest using a runtests.py file there.
comment:14 by , 6 years ago
I don't see a reason for shipping a runtests.py
file with minimal configuration. The one we use for Django's testsuite happens to exist because we need to perform quite a lot of tweaks before running the tests which isn't the case for most Django third party apps.
comment:15 by , 6 years ago
Cc: | removed |
---|
comment:16 by , 6 years ago
Patch needs improvement: | set |
---|
Patch looks good. Comments on PR (Summary: Just some rewording to the "Advanced testing topics" section linked from the new examples needed.)
comment:17 by , 9 months ago
Owner: | removed |
---|---|
Status: | assigned → new |
follow-up: 19 comment:18 by , 9 months ago
Owner: | set to |
---|---|
Status: | new → assigned |
I forgot about this completely. I'll just fix up the branch and add in the feedback.
comment:19 by , 9 months ago
Replying to Raphael Kimmig:
I forgot about this completely. I'll just fix up the branch and add in the feedback.
Great, thanks!
comment:20 by , 9 months ago
I wasn't able to change the target branch on the old PR to main, so here is a new one incorporating feedback from the old PR
comment:21 by , 7 months ago
Patch needs improvement: | unset |
---|
comment:22 by , 6 months ago
Patch needs improvement: | set |
---|
I concur 100%. The distinction between integration testing of new apps, and system testing of a specific app is a persistent problem, and the cause of more than one ticket in the Django system (e.g., #10976, #10755, and others). This is a problem for which we should have a solid answer.