#36313 closed Bug (worksforme)
even with `reset_sequences=True` a class does not reset them on teardown
Reported by: | anthony sottile | Owned by: | |
---|---|---|---|
Component: | Testing framework | Version: | dev |
Severity: | Normal | Keywords: | reset_sequences |
Cc: | Jacob Walls | Triage Stage: | Unreviewed |
Has patch: | no | Needs documentation: | no |
Needs tests: | no | Patch needs improvement: | no |
Easy pickings: | no | UI/UX: | no |
Description (last modified by )
I have a particular test class which I know breaks primary key ordering for a bunch of other tests in the process. I figured I could extend TransactionTestCase
and set reset_sequences = True
on this class but the sequence state persists after the test
seems this was improved in https://code.djangoproject.com/ticket/18271
I believe this minimal patch would fix it :
diff --git a/django/test/testcases.py b/django/test/testcases.py index 8f9ba977a3..e2cf63b56d 100644 --- a/django/test/testcases.py +++ b/django/test/testcases.py @@ -1239,7 +1239,7 @@ class TransactionTestCase(SimpleTestCase): verbosity=0, interactive=False, database=db_name, - reset_sequences=False, + reset_sequences=self.reset_sequences, allow_cascade=self.available_apps is not None, inhibit_post_migrate=inhibit_post_migrate, )
I'm specifically using django 5.1.7 but given the code this also affects the in-development version
Change History (3)
comment:1 by , 6 months ago
Description: | modified (diff) |
---|
comment:2 by , 6 months ago
Cc: | added |
---|---|
Component: | Uncategorized → Testing framework |
Keywords: | reset_sequences added |
Resolution: | → needsinfo |
Status: | new → closed |
Type: | Uncategorized → Bug |
comment:3 by , 5 months ago
Resolution: | needsinfo → worksforme |
---|
Thanks for the CC.
The reset_sequence
attribute is doc'd to affect test setup, not teardown, on the idea that test cases that are sensitive to primary key ordering should be opting in to the reset overhead by setting reset_sequences=True
. So under the current paradigm, the sequence state persisting after the test is expected.
Changing this, I think, would require an impact analysis (DEP-lite?) on test case ordering and any usability or performance upsides from changing the behavior you called out.
Hello anthony sottile, thank you for taking the time to create this report. We can't provide a solution from a diff, would need really need either or both:
I'll be closing this ticket as
needsinfo
, but please reopen when you can provide precise details on how to reproduce locally.