Opened 17 years ago

Closed 14 years ago

#5624 closed (wontfix)

Add mechanism for associating fixtures with doctests

Reported by: eikke@… 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 Russell Keith-Magee)

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)

0001-Add-pre_test-signal.patch (2.6 KB ) - added by eikke@… 17 years ago.
Add pre_test signal
doctest-fixtures.diff (2.9 KB ) - added by jkocherhans 17 years ago.
This time with tests.

Download all attachments as: .zip

Change History (12)

by eikke@…, 17 years ago

Add pre_test signal

comment:1 by Russell Keith-Magee, 17 years ago

Component: UncategorizedUnit test system
Description: modified (diff)
Patch needs improvement: set
Summary: Add pre_test signalAdd mechanism for associating fixtures with doctests
Triage Stage: UnreviewedAccepted

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 jkocherhans, 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.

by jkocherhans, 17 years ago

Attachment: doctest-fixtures.diff added

This time with tests.

comment:3 by jkocherhans, 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 jkocherhans, 17 years ago

Needs documentation: set

comment:5 by jkocherhans, 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 remo, 16 years ago

Has patch: unset

We could introduce a new 'doctest directive' to load fixtures:

    # LOAD_FIXTURE 'test.fixture'

    >>> runtests

This enables us to load fixtures on a per test basis. Without the need to call in each doctest.

Of course, this kind of directive is not supported by vanilla doctests. We could implement this in (, but that feels hackish. What would be a better way to do this?

comment:7 by Jacob, 16 years ago

See #8835 for another twist on how this shakes out in practice.

comment:8 by Malcolm Tredinnick, 16 years ago

(In [8930]) Changed the tests added in r8898 very slightly so that they don't return
unintended results. Doctests aren't self-contained yet when run as part of
the full suite. Refs #5624, #8835.

comment:9 by Kevin Kubasik, 15 years ago

Owner: changed from nobody to Kevin Kubasik

comment:10 by Eric Holscher, 14 years ago

Resolution: wontfix
Status: newclosed

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.

Note: See TracTickets for help on using tickets.
Back to Top