testing on roschegel

Simplified Django Tests With Pytest and Pytest FactoryBoy

Sun, 17 May 2020 00:00:00 +0000

I’m always trying to find ways to make tests easier to read and extend. I hate working through a really hard feature and having to spend a big amount of time writing tests.

Lately, I’ve been bothered by the amount of boilerplate on my test code. So, I decided to do some research and look for alternatives.

When testing Django applications, I use a combination of Pytest fixtures and FactoryBoy to write tests that need database records.

Pytest Fixtures allow you to abstract the initialization of your test cases into functions (fixtures) and help you re-use code. Pytest uses dependency injection to detect when a fixture is needed on a test by matching the name provided on the parameter with the name of the fixture. Learn more about Pytest Fixtures on the Pytest documentation.
FactoryBoy allows you to create factories for your models with pre-defined values, which makes it easy to create model objects on the go. It handles relationships by allowing you to define subfactories and integrates with the faker library to provide the ability to use randomized values. It’s a good alternative to Django fixtures.

The Problem

Let’s look through an example to understand what we are trying to fix.

We will write a test case for the following function which returns a list of Post’s titles:

def get_posts_titles(include_unpublished=False):
    queryset = Post.objects.all()
    if not include_unpublished:
        queryset = queryset.filter(status="published")
    return  list(queryset.values_list("title", flat=True))

First, in factories.py we define the factory that will later be used to create the model objects on the test. In this case, it’s just a simple database with a Post model. So we just need one factory:

import factory

class PostFactory(factory.django.DjangoModelFactory):
    title = "Combining Pytest and FactoryBoy for simplified tests in Django"
    status = "draft"

    class Meta:
        model = "blog.Post"

Then in the test_posts.py file, we import the factory and create 2 fixtures that use it, post_draft and post_published:

import pytest

from factories import PostFactory


@pytest.fixture
def post_draft():
    return PostFactory()


@pytest.fixture
def post_published():
    return PostFactory(status="published")


@pytest.mark.django_db
def test_get_posts_titles(post_published, post_draft):
    assert get_posts_titles() == [post_published.title]
    assert get_posts_titles(include_unpublished=True) == [post_published.title, post_draft.title]

Notice the amount of boilerplate on the code, we had to:

create a PostFactory on the factories.py file;
create a fixture for a draft post;
create a fixture for a published post.

Avoiding boilerplate code with pytest-factoryboy

Let’s see how we could re-write the code from the previous section using pytest-factoryboy.

We’ll still have the factories defined in the factories.py file:

import factory


class PostFactory(factory.django.DjangoModelFactory):
    title = "Combining Pytest and FactoryBoy for simplified tests in Django"
    status = "draft"

    class Meta:
        model = "blog.Post"

But now, we register that factory in conftests.py so that it is available as a fixture for all tests:

from pytest_factoryboy import register

from factories import PostFactory


register(PostFactory)
register(PostFactory, "draft_post", title="Draft post", status="draft")

The fixture will take the name of the Factory (post by default) but you can optionally provide it a name. Two fixtures will be created: post and draft_post.

Then, in the tests, we can start using the registered fixtures:

import pytest

from blog.utils import get_posts_titles


@pytest.mark.django_db
def test_get_posts_titles(post, draft_post):
    assert get_posts_titles() == [post.title]
    assert get_posts_titles(include_unpublished=True) == [post.title, draft_post.title]

Since pytest-factoryboy took care of registering the factories as fixtures for us, we won’t need to:

manually create the fixtures;
manually import the PostFactory on the test file.

More about pytest-factoryboy

Being able to register a factory as a fixture is just one of pytest-factoryboy’s features. Let’s see some more.

Set custom attribute values for you model fixtures

There will be some test cases in which you need to customize an attribute of your model fixture. You can easily do so using pytest.mark.parametrize:

import pytest

from blog.utils import get_posts_titles


@pytest.mark.django_db
@pytest.mark.parametrize("post__title", ["Custom title"])
@pytest.mark.parametrize("post_draft__title", ["Custom title - Draft"])
def test_get_posts_titles(post, draft_post):
    assert get_posts_titles() == ["Custom title"]
    assert get_posts_titles(include_unpublished=True) == ["Custom title", "Custom title - Draft"]

Override a fixture’s value

If you are modifying the same attribute on multiple test functions within a module, you can opt to override the attribute on the fixture for the entire module. The following code will set post.status to "draft" for the entire module:

import pytest

from blog.utils import get_posts_titles


@pytest.fixture
def post__status():
    """Override blog's status to draft."""
    return "draft"


@pytest.mark.django_db
def test_get_posts_titles(post):
    assert get_posts_titles() == []
    assert get_posts_titles(include_unpublished=True) == [post.title]

Factories are automatically registered as fixtures

Sometimes you will just want to interact with the factory directly, without using the model fixture (e.g. post). pytest-factoryboy automatically registers the factory as a fixture too. Notice that the fixture name is the snake_case version of the factory name:

import pytest

from blog.utils import get_posts_titles


@pytest.mark.django_db
def test_get_posts_titles(post_factory):
    post = post_factory(status="draft")
    assert get_posts_titles() == []
    assert get_posts_titles(include_unpublished=True) == [post.title]

Assign other fixtures as values with parametrize

When your models have ForeignKey relationships you might want to assign another fixture as the value. You can do so using parametrize and LazyFixture.

Given a Post with a blog attribute as a ForeignKey, we could have the following factories:

import factory


class BlogFactory(factory.django.DjangoModelFactory):
    name = "roschegel"

    class Meta:
        model = "blog.Blog"


class PostFactory(factory.django.DjangoModelFactory):
    title = "Combining Pytest and FactoryBoy for simplified tests in Django"
    status = "draft"
    blog = factory.SubFactory(BlogFactory)

    class Meta:
        model = "blog.Post"

In our test case we could then override the blog attribute using LazyFixture:

import pytest

from pytest_factoryboy import LazyFixture


@pytest.fixture
def blog_2(blog_factory):
    return blog_factory(name="some_other_blog")


@pytest.mark.django_db
@pytest.mark.parametrize("post__blog", [LazyFixture("blog_2")])
def test_lazy_fixture(post, blog_2):
    assert post.blog.id == blog_2.id

Wrapping up

Next time you find yourself writing factories and fixtures that just return instances of your models, consider using pytest-factoryboy. It will save you a considerable amount of boilerplate code. And that means more time to work on meaningfull stuff, which is always welcome.

Making your Django tests faster

Sat, 09 May 2020 00:00:00 +0000

Tests need to be fast. If tests are slow, our development process is affected and we end up spending a considerable amount of time waiting for the results.

I will go through some of the techniques that I’ve applied to speed up tests on Django applications.

Tips for speeding up test execution

1. Run your tests in parallel

If you are running your tests on multi-core hardware, running your tests in parallel is probably the best optimization you can make if you aren’t doing it yet.

If you are using pytest, install the pytest-xdist plugin:

$ pip install pytest-xdist

And then run your tests with the -n parameter:

$ pytest -n auto

The -n parameter accepts either a number, indicating the number of cores in which you would like to run the tests, or the value auto in which case the plugin will automatically detect the number of cores that are available on your machine and use them all.

If you are using the Django test runner, simply run the tests using the --parallel parameter:

$ ./manage.py test --parallel

You can also indicate the specific number of cores in which you would like your tests to run by providing a number:

$ ./manage.py test --parallel 4

2. Use fixtures for modularized setup (Pytest only)

In the typical xUnit based testing frameworks (such as unittest) you create a setup method within your test class in which you set up everything you need for your tests.

Pytest fixtures are a replacement for the conventional setup method. To declare a fixture, you create a function and decorate it with the @pytest.fixture decorator.

To use a fixture on a test case you can:

Make it run automatically for each test case with the autouse parameter: @pytest.fixture(autouse=True)
Add it to your test case parameter list. This will trigger the fixture to be executed.
Add the usefixtures mark decorator to your test class: @pytest.mark.usefixtures("your_fixture")

One of the greatest advantages of using fixtures is that you can modularize your setup into smaller and less generic functions.

By splitting your setup method into multiple methods, you will be able to select only the ones you need for each test case. This will ensure that you execute exactly what is needed for each test case and nothing else.

3. Use the database only when it is needed

It is common to see lots of database records being created on the setup method of a test class. Usually, not all the records are used by all the test cases, but they still get created each time.

Make sure you only create the records that will be used by all the tests on your setup method. If there is a database record that is not being used by all the test cases, either:

Move it to a fixture (if you are using pytest)
Move it to the specific test where you need it

4. Search for the slowest tests and look for possible optimizations (Pytest only)

Pytest provides a way to find which are the slowest tests by executing them using the --durations parameter.

The following example command will execute all the tests and print a summary at the end with a list of the 5 tests that took the longest to run:

$ pytest --durations=5

5. Squash your migrations

Consider squashing your migrations if you have too many. Squashing refers to reducing the number of migrations you have by merging them into one.

Migrations are run each time you execute your test suite. Squashing migrations would not only speed up your tests but also your development setup.

Tips for speeding up your tests execution locally

When running tests locally while developing a new feature, fixing a bug or refactoring, there are few more things you can do to speed up your tests:

1. Re-use the database among test runs

Every time you run your Django tests, a new test database is created, this takes a considerable amount of time. When you are not making changes to your models or migration files, you can skip this step by telling the runner that you want to preserve the database among test executions.

If you are using Pytest, you can use pytest-django’s --reuse-db parameter:

$ pytest --reuse-db

If you are using the Django test runner you can accomplish the same with the --keep-db parameter:

$ ./manage.py test --keep-db

2. Disable Migrations with —no-migrations

When the test runner starts, the database is created and migrations run one by one to reach the current state of your models. If you choose to run your tests without executing the migrations, Django will create the database using the current state of your models.

Skipping migrations should be safe unless you are making changes to your migrations, in which case you would also want to ensure they are working as expected.

Depending on the number of migrations you have, they could take a lot of time. But most of the time, while testing locally, we don’t need them to run.

To disable migrations, include the --no-migrations parameter:

$ pytest --no-migrations

Or with the Django test runner:

$ ./manage.py test --no-migrations

3. Run only the tests that failed on the last run (Pytest only)

If you just need to know if the tests that were previously failing are still failing, use pytest’s --lf parameter:

$ pytest --lf

Wrapping up

Ensuring tests run fast is key to having a healthy project. Applying these techniques should help you take your first steps into faster and more efficient tests with Django.

If your application is big enough you might want to consider applying the Repository Pattern and making your tests completely independent of the database.