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.