Changes between Initial Version and Version 1 of Ticket #5624

09/27/07 12:56:31 (15 years ago)
Russell Keith-Magee

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.


  • Ticket #5624

    • Property Patch needs improvement set
    • Property Triage Stage changed from Unreviewed to Accepted
    • Property Component changed from Uncategorized to Unit test system
    • Property Summary changed from Add pre_test signal to Add mechanism for associating fixtures with doctests
  • 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.
     3Ref #5608 for a previously rejected proposal.
Back to Top