Code

Changes between Initial Version and Version 1 of Ticket #5624


Ignore:
Timestamp:
09/27/07 05:56:31 (7 years ago)
Author:
russellm
Comment:

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.

Legend:

Unmodified
Added
Removed
Modified
  • Ticket #5624

    • Property Patch needs improvement set
    • Property Component changed from Uncategorized to Unit test system
    • Property Needs tests unset
    • Property Summary changed from Add pre_test signal to Add mechanism for associating fixtures with doctests
    • Property Needs documentation unset
    • Property Triage Stage changed from Unreviewed to Accepted
  • Ticket #5624 – Description

    initial v1  
    1 As #5608 was rejected but in our setup we'd still like to be able to load test data in the test database, without polluting the actual doctests (which are mostly used for example/documentation purposes), I went another route and created a new signal, similar to post_syncdb. It's called pre_test and is sent after test database creation, before tests are run. This way it is possible to do some pre-test setup in application management modules (I eg use it to run call_command to loaddata some test_data fixture). 
     1It would be useful to be able to associate fixtures with a doctest without the need to add fixture loading code to the doctest.  
     2 
     3Ref #5608 for a previously rejected proposal.