Django Test Data

Django Test Data

Most slow Django suites spend time building data they do not need or exercising full request/database paths for behavior that can be tested at a smaller boundary. Use this skill to reduce setup cost while keeping representative integration coverage.

Refactoring Workflow

1. Map the behavior under test.

   • Identify the smallest useful boundary: function, form, model method, middleware, command helper, view, or full request path.
   • Keep a few integration tests for wiring; move detailed cases to unit tests where the boundary is clean.

2. Choose the fastest test base class.

   • SimpleTestCase: no database access.
   • TestCase: ordinary database tests with rollback.
   • TransactionTestCase: committed transaction behavior only.
   • LiveServerTestCase: browser/live-server tests only.

3. Remove broad fixture data.

   • Avoid large fixture files and base classes that always create objects.
   • Build only the data each test or class needs.

4. Use factories deliberately.

   • Start with small factory functions when the domain is simple.
   • Use Factory Boy or Model Bakery when relationships and variants become repetitive.

5. Share class-level data with setUpTestData.

   • Use setUpTestData() for database objects reused by multiple methods in a TestCase.
   • Avoid mutating shared in-memory objects across methods.

6. Optimize database access in test setup and assertions.

   • Use select_related, prefetch_related, or bulk_create where setup/query cost is the bottleneck.
   • Assert query counts for hot paths when performance is part of the contract.

Read patterns.md for examples and decision details.

Decision Rules

• If a test does not need the database, use SimpleTestCase.
• If only some tests need the database, split them into separate classes.
• If a test requires committed transaction behavior, first check whether captureOnCommitCallbacks() or an inner atomic() is enough.
• If many tests share expensive objects, use setUpTestData instead of setUp.