Opened 8 years ago

Closed 5 years ago

#5624 closed (wontfix)

Add mechanism for associating fixtures with doctests

Reported by: eikke@… Owned by: kkubasik
Component: Testing framework Version: master
Severity: Keywords:
Cc: Triage Stage: Accepted
Has patch: no Needs documentation: yes
Needs tests: no Patch needs improvement: no
Easy pickings: UI/UX:

Description (last modified by russellm)

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

Download all attachments as: .zip

Change History (12)

Changed 8 years ago by eikke@…

Add pre_test signal

comment:1 Changed 8 years ago by russellm

  • Component changed from Uncategorized to Unit test system
  • Description modified (diff)
  • Needs documentation unset
  • Needs tests unset
  • Patch needs improvement set
  • Summary changed from Add pre_test signal to Add mechanism for associating fixtures with doctests
  • Triage Stage changed from Unreviewed to 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 Changed 8 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 8 years ago by jkocherhans

This time with tests.

comment:3 Changed 8 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 8 years ago by jkocherhans

  • Needs documentation set

comment:5 Changed 8 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 8 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 7 years ago by jacob

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

comment:8 Changed 7 years ago by mtredinnick

(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 7 years ago by kkubasik

  • Owner changed from nobody to kkubasik

comment:10 Changed 5 years ago by ericholscher

  • Resolution set to wontfix
  • Status changed from new to 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.

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