Code

Opened 11 months ago

Last modified 11 months ago

#20392 new New feature

Rearrange transactional behavior in django.test.TestCase: savepoints around tests

Reported by: xelnor Owned by: nobody
Component: Testing framework Version: master
Severity: Normal Keywords: test atomic savepoint
Cc: charettes Triage Stage: Accepted
Has patch: no Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: no UI/UX: no

Description

Leveraging aaugustin's work on atomic(), this patch modifies the behavior of django.test.TestCase:

  • A transaction is opened during setUpClass (one atomic per database)
  • That transaction is closed during tearDownClass
  • The database connection is no longer closed after each test function

This allows to create objects and complex state in setUpClass, and reuse it through all test functions,
without inter-test conflicts.

This could lead to a single load of fixtures during setUpClass (instead of the current setUp), thus improving test speed.

Attachments (1)

refactor_testcase_transactions.diff (7.8 KB) - added by xelnor 11 months ago.
Patch against commit 327e362

Download all attachments as: .zip

Change History (5)

Changed 11 months ago by xelnor

Patch against commit 327e362

comment:1 Changed 11 months ago by aaugustin

  • Needs documentation unset
  • Needs tests unset
  • Patch needs improvement unset
  • Triage Stage changed from Unreviewed to Accepted

Yes, this is a good idea.

comment:2 Changed 11 months ago by aaugustin

I'm not sure about reset_connections_per_test. Closing the connections during the execution of the tests breaks with in-memory SQLite. What is this parameter designed to achieve? Is it intended as a public API?

comment:3 Changed 11 months ago by xelnor

The reset_connections_per_test attribute is here to avoid duplicating the logic in TransactionTestCase._post_teardown.
The current behavior (see https://github.com/django/django/blob/master/django/test/testcases.py#L516) is to close all database connections after self.tearDown.

I wanted to be able to distinguish between TransactionTestCase, where this connection closure is required for database reset, and TestCase, where it should be avoided to gain the features discussed above.

Put another way, the current behaviour is:

  • TransactionTestCase recreates the database and loads fixtures before each test_foo; closes the connection after each test_foo.
  • TestCase creates the database once, loads TestCase-specific fixtures before each test_foo; rolls back the transaction and closes the connection after each test_foo.

The goal is:

  • No change to TransactionTestCase
  • TestCase creates the database once, begins a transaction at setUpClass where it loads TestCase-specific fixtures, makes a savepoint before each test_foo, rolls back to savepoint after each test_foo, rolls back the transaction then closes connections in tearDownClass.

I'll try to upgrade the patch with more comments, and move the "load fixtures" code to setUpClass.
This discussion should probably move to django-developers@, what do you think?

comment:4 Changed 11 months ago by charettes

  • Cc charettes added

Add Comment

Modify Ticket

Change Properties
<Author field>
Action
as new
The owner will be changed from nobody to anonymous. Next status will be 'assigned'
as The resolution will be set. Next status will be 'closed'
Author


E-mail address and user name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.