On May 4, 10:09 am, Andreas Pelme <[email protected]> wrote:
> Here's the ticket:
>
> https://code.djangoproject.com/ticket/18271
>
> … and an initial patch:
>
> https://github.com/django/django/pull/45
I marked the ticket DDN, there are three reasons:
1. If a test case screws up cleanup it will cause problems for
itself currently, after the patch it will cause problems for the next
test case which makes debugging much harder.
2. Is this backwards incompatible? The behavior was documented.
3. Is there some reason why the flush must be done pre-test which
we are overlooking. Why was it implemented that way originally?
Perhaps because of the first item?
Each test case taking care of cleaning up after itself feels like the
right way to go. There are a couple of reasons:
- TestCase works already this way: it doesn't do cleanup before, it
just makes sure it cleans after itself (which is easy as it doesn't
leave any trash behind).
- The database is treated specially. The tests trust other tests to
clean up their state. Settings is an example.
- As said upthread, this allows for special test case subclasses
which do more intelligent cleanup. I don't think an intelligent
TransactionTestCase subclass which doesn't run flush pre-tests is
possible in the current implementation, as it would then see the trash
of other TransactionTestCases.
But, as said, I left the ticket DDN. None of the issues mentioned
above seem like a blocker. The backwards incompatibility is the most
likely blocker - I can't see that changing the behavior is going to
cause problems, but maybe there are users out there whose test cases
somehow require pre-test flush?
- Anssi
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en.
