Opened 17 years ago
Closed 14 years ago
#5624 closed (wontfix)
Add mechanism for associating fixtures with doctests
Reported by: | Owned by: | Kevin Kubasik | |
---|---|---|---|
Component: | Testing framework | Version: | dev |
Severity: | Keywords: | ||
Cc: | Triage Stage: | Accepted | |
Has patch: | no | Needs documentation: | yes |
Needs tests: | no | Patch needs improvement: | no |
Easy pickings: | no | UI/UX: | no |
Description (last modified by )
It would be useful to be able to associate fixtures with a doctest without the need to add fixture loading code to the doctest.
Ref #5608 for a previously rejected proposal.
Attachments (2)
Change History (12)
by , 17 years ago
Attachment: | 0001-Add-pre_test-signal.patch added |
---|
comment:1 by , 17 years ago
Component: | Uncategorized → Unit test system |
---|---|
Description: | modified (diff) |
Patch needs improvement: | set |
Summary: | Add pre_test signal → Add mechanism for associating fixtures with doctests |
Triage Stage: | Unreviewed → Accepted |
The pre-test signal approach in the patch is no better than the appropach proposed in #5608. Test fixtures are applicable on a _per test_ basis.
However, I can accept the general use case you describe. I agree that it would be nice to be able to associate fixtures with a doctest without the need to insert the applicable code at the start of the test. I've modified the summary and description to reflect the underlying feature request, rather than the specific solution.
If you're looking at how to implement this, I would suggest looking at associating a fixtures attribute with the docstring itself, and modifying the Django doctest runner to look for the fixtures attribute.
comment:2 by , 17 years ago
So adding a fixtures
attribute to the doctest is probably out of the question since you can't add arbitrary attributes to strings. I've attached a patch that loads data from a fixtures
attribute is it is found in the DocTest
instance's globs
attribute. This feels pretty dirty, but it works. Maybe making fixtures
into a double under name might make it slightly less dirty, or at least make it harder to accidentally load stuff. I dunno. I don't really see many other ways to do this after digging into the doctest code though. If this is too nasty, the ticket should probably just be closed.
comment:3 by , 17 years ago
Patch needs improvement: | unset |
---|
So the current patch will call flush for every doctest and load any fixtures found in a module global called __fixtures__
if it exists.
comment:4 by , 17 years ago
Needs documentation: | set |
---|
comment:5 by , 17 years ago
Calling flush for every doctest probably isn't acceptable. I'm still thinking about it, but it's a nasty problem.
See #4998 and this thread for more.
comment:6 by , 17 years ago
Has patch: | unset |
---|
We could introduce a new 'doctest directive' to load fixtures:
""" # LOAD_FIXTURE 'test.fixture' >>> runtests True """
This enables us to load fixtures on a per test basis. Without the need to call django.core.management.call_command in each doctest.
Of course, this kind of directive is not supported by vanilla doctests. We could implement this in django.test.testcases.DocTestRunner.run (http://dpaste.com/34517/), but that feels hackish. What would be a better way to do this?
comment:8 by , 16 years ago
comment:9 by , 16 years ago
Owner: | changed from | to
---|
comment:10 by , 14 years ago
Resolution: | → wontfix |
---|---|
Status: | new → closed |
Going to close this one as wontfix because we are moving away from encouraging the use of doctests. Given that Django has no method for running doctests in a transaction, this will also cause tests to become really slow, or leak data into other tests.
I can see how this might be useful for users, however, if you are using fixtures in a doctest, this is probably a sign that you need to be using unit tests instead, and we should be helping users see the light.
If a core dev feels this is wrong, feel free to repoen.
Add pre_test signal