The first solution we will take a look at is what is given in the Django documentation itself, that is, test fixtures. Here, a test fixture is a file that contains a set of data that can be imported into your database to bring it to a known state. Typically, they are YAML or JSON files previously exported from the same database when it had some data.

For example, consider the following test case, which uses a test fixture:

from django.test import TestCase 
 
class PostTestCase(TestCase): 
    fixtures = ['posts'] 
 
    def setUp(self): 
        # Create additional common objects 
        pass 
 
    def test_some_post_functionality(self): 
        # By now fixtures and setUp() objects are loaded 
        pass 

Before setUp() gets called in each test case, the specified fixture, 'posts', gets loaded. Roughly speaking, the fixture will be searched for in the fixtures directory with certain known extensions, for example, app/fixtures/posts.json.

However, there are a number of problems with fixtures. Fixtures are static snapshots of the database. They are schema-dependent and have to be changed each time your models change. They also might need to be updated when your test-case assertions change. Updating a large fixture file manually, with multiple related objects, is no joke.

For all these reasons, many consider using fixtures as an anti-pattern. It is recommended that you use factories instead. A factory class creates objects of a particular class that can be used in tests. It is a DRY way of creating initial test objects.

Let's use a model's objects.create method to create a simple factory:

from django.test import TestCase 
from .models import Post 
 
class PostFactory: 
    def make_post(self): 
        return Post.objects.create(message="") 
 
class PostTestCase(TestCase): 
 
    def setUp(self): 
        self.blank_message = PostFactory().makePost() 
 
    def test_some_post_functionality(self): 
        pass 

Compared to using fixtures, the initial object creation and the test cases are all in one place. Fixtures load static data as is into the database without calling model-defined save() methods. Since factory objects are dynamically generated, they are more likely to run through your application's custom validations.

However, there is a lot of boilerplate in writing such factory classes yourself. The factory_boy package, based on thoughtbot's factory_girl, provides a declarative syntax for creating object factories.

When you rewrite the previous code to use factory_boy, we get the following result:

import factory 
from django.test import TestCase 
from .models import Post 
 
class PostFactory(factory.Factory): 
    class Meta: 
        model = Post 
    message = "" 
 
class PostTestCase(TestCase): 
 
    def setUp(self): 
        self.blank_message = PostFactory.create() 
        self.silly_message = PostFactory.create(message="silly") 
 
    def test_post_title_was_set(self): 
        self.assertEqual(self.blank_message.message, "") 
        self.assertEqual(self.silly_message.message, "silly") 

Note how clear the factory class becomes when written in a declarative fashion. The attribute's values do not have to be static. You can have sequential, random, or computed attribute values. If you prefer to have more realistic placeholder data such as US addresses, use the django-faker package.

In conclusion, I would recommend factories, especially factory_boy, for most projects that need initial test objects. You might still want to use fixtures for static data, such as lists of countries or t-shirt sizes, since they will rarely change.