Since then the [https://github.com/charettes/django-testdata third-party
app] implementing this feature has not received much feedback but I know a
few developers have been using it and my usage in a few projects didn't
surface any issues.
---
Django 1.8 introduced the `TestCase.setUpTestData()` class method as a
mean to
speed up test fixtures initialization as compared to using `setUp()`.
As I've come to use this feature and review changes from peers using it in
different projects the fact that test data assigned during its execution
couldn't be safely altered by test methods without compromising test
isolation
has often be the source of confusion and frustration.
While the `setUpTestData` documentation mentions this limitation[1] and
ways to
work around it by using `refresh_from_db()` in `setUp()` I believe it
defeats
the whole purpose of the feature; avoiding unnecessary roundtrips to the
database to speed up execution. Given `TestCase` goes through great
lengths to
ensure database level data isolation I believe it should do the same with
class
level in-memory data assigned during `setUpTestData`.
In order to get rid of this caveat of the feature I'd like to propose an
adjustment to ensure such in-memory test data isolation.
--
Ticket URL: <https://code.djangoproject.com/ticket/31395>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
* cc: Adam (Chainz) Johnson (added)
* version: 3.0 => master
--
Ticket URL: <https://code.djangoproject.com/ticket/31395#comment:1>
* has_patch: 0 => 1
--
Ticket URL: <https://code.djangoproject.com/ticket/31395#comment:2>
* owner: nobody => Simon Charette
* status: new => assigned
* stage: Unreviewed => Accepted
Comment:
[https://github.com/django/django/pull/12608 PR]
--
Ticket URL: <https://code.djangoproject.com/ticket/31395#comment:3>
* stage: Accepted => Ready for checkin
--
Ticket URL: <https://code.djangoproject.com/ticket/31395#comment:4>
* status: assigned => closed
* resolution: => fixed
Comment:
In [changeset:"3cf80d3fcf7446afdde16a2be515c423f720e54d" 3cf80d3f]:
{{{
#!CommitTicketReference repository=""
revision="3cf80d3fcf7446afdde16a2be515c423f720e54d"
Fixed #31395 -- Made setUpTestData enforce in-memory data isolation.
Since it's introduction in Django 1.8 setUpTestData has been suffering
from a documented but confusing caveat due to its sharing of attributes
assigned during its execution with all test instances.
By keeping track of class attributes assigned during the setUpTestData
phase its possible to ensure only deep copies are provided to test
instances on attribute retreival and prevent manual setUp gymnastic to
work around the previous lack of in-memory data isolation.
Thanks Adam Johnson for the extensive review.
}}}
--
Ticket URL: <https://code.djangoproject.com/ticket/31395#comment:5>
Comment (by Mariusz Felisiak <felisiak.mariusz@…>):
In [changeset:"94f63b926fd32d7a7b6e2591ef72aa8f040f25cc" 94f63b92]:
{{{
#!CommitTicketReference repository=""
revision="94f63b926fd32d7a7b6e2591ef72aa8f040f25cc"
Refs #31395 -- Relied on setUpTestData() test data isolation in various
tests.
}}}
--
Ticket URL: <https://code.djangoproject.com/ticket/31395#comment:6>
Comment (by Mariusz Felisiak <felisiak.mariusz@…>):
In [changeset:"2e10abeb7f375d56dca21b1baed11f98e74ab7f5" 2e10abe]:
{{{
#!CommitTicketReference repository=""
revision="2e10abeb7f375d56dca21b1baed11f98e74ab7f5"
Refs #31395 -- Removed support for assigning objects which don't support
deepcopy() in setUpTestData().
Per deprecation timeline.
}}}
--
Ticket URL: <https://code.djangoproject.com/ticket/31395#comment:7>