Opened 16 years ago

Closed 13 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@… 16 years ago.
Add pre_test signal
doctest-fixtures.diff (2.9 KB) - added by jkocherhans 16 years ago.
This time with tests.

Download all attachments as: .zip

Change History (12)

Changed 16 years ago by eikke@…

Add pre_test signal

comment:1 Changed 16 years ago by Russell Keith-Magee

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 Changed 16 years ago by jkocherhans

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.

Changed 16 years ago by jkocherhans

Attachment: doctest-fixtures.diff added

This time with tests.

comment:3 Changed 16 years ago by jkocherhans

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 Changed 16 years ago by jkocherhans

Needs documentation: set

comment:5 Changed 16 years ago by jkocherhans

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 Changed 16 years ago by remo

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 Changed 15 years ago by Jacob

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

comment:8 Changed 15 years ago by Malcolm Tredinnick

(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 Changed 14 years ago by Kevin Kubasik

Owner: changed from nobody to Kevin Kubasik

comment:10 Changed 13 years ago by Eric Holscher

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