# Reuse the test-database (since django version 1.8) $ python manage.py test -keepdb Limit the number of tests executed. It is possible to limit the tests executed by manage.py test by specifying which modules should be discovered by the test runner.

• Django Test Case
• Django Nose Test Runner
• Django Test Runner Pytest
• Django Test Client
• Django Transactiontestcase

Testing is an important but often neglected part of any Django project. In this tutorial we'll review testing best practices and example code that can be applied to any Django app.

1. Adds support for running Django tests in Visual Studio Code. Provides shortcuts to run closest method, class, file, app and previous tests. Provides support for Django-Nose in settings. Draws inspiration from vscode-django-tests and vim-python-test-runner.
2. The first problem you’ll run in to when trying to write a test that runs a task is that Django’s test runner doesn’t use the same database as your celery daemon is using. If you’re using the database backend, this means that your tombstones won’t show up in your test database and you won’t be able to get the return value or check.

Broadly speaking there are two types of tests you need to run:

• Unit Tests are small, isolated, and focus on one specific function.
• Integration Tests are aimed at mimicking user behavior and combine multiple pieces of code and functionality.

While we might we use a unit test to confirm that the homepage returns an HTTP status code of 200, an integration test might mimic the entire registration flow of a user.

For all tests the expectation is that the result is either expected, unexpected, or an error. An expected result would be a 200 response on the homepage, but we can--and should--also test that the homepage does not return something unexpected, like a 404 response. Anything else would be an error requiring further debugging.

The main focus of testing should be unit tests. You can't write too many of them. They are far easier to write, read, and debug than integration tests. They are also quite fast to run.

Complete source code is available on Github.

When to run tests

The short answer is all the time! Practically speaking, whenever code is pushed or pulled from a repo to a staging environment is ideal. A continuous integration service can perform this automatically. You should also re-run all tests when upgrading software packages, especially Django itself.

Layout

By default all new apps in a Django project come with a tests.py file. Any test within this file that starts with test_ will be run by Django's test runner. Make sure all test files start with test_.

As projects grow in complexity, it's recommended to delete this initial tests.py file and replace it with an app-level tests folder that contains individual tests files for each area of functionality.

For example:

Sample Project

Let's create a small Django project from scratch and thoroughly test it. It will mimic the message board app from Chapter 4 of Django for Beginners.

On the command line run the following commands to start our new project. We'll place the code in a folder called testy on the Desktop, but you can locate the code anywhere you choose.

Now update settings.py to add our new pages app and configure Django to look for a project-level templates folder.

Create our two templates to test for a homepage and about page.

Populate the templates with the following simple code.

Update the project-level urls.py file to point to the pages app.

Create a urls.py file within the pages app.

Then update it as follows:

And as a final step add our views.

Start up the local Django server.

Then navigate to the homepage at http://127.0.0.1:8000/ and about page at http://127.0.0.1:8000/about to confirm everything is working.

Time for tests.

Django Test Case

SimpleTestCase

Our Django application only has two static pages at the moment. There's no database involved which means we should use SimpleTestCase.

We can use the existing pages/tests.py file for our tests for now. Take a look at the code below which adds five tests for our homepage. First we test that it exists and returns a 200 HTTP status code. Then we confirm that it uses the url named home. We check that the template used is home.html, the HTML matches what we've typed so far, and even test that it does not contain incorrect HTML. It's always good to test both expected and unexpected behavior.

Now run the tests.

They should all pass.

As an exercise, see if you can add a class for AboutPageTests in this same file. It should have the same five tests but will need to be updated slightly. Run the test runner once complete. The correct code is below so try not to peak...

Message Board app

Now let's create our message board app so we can try testing out database queries. First create another app called posts.

Add it to our settings.py file.

Then run migrate to create our initial database.

Now add a basic model.

Create a database migration file and activate it.

For simplicity we can just a post via the Django admin. So first create a superuser account and fill in all prompts.

Update our admin.py file so the posts app is active in the Django admin.

Then restart the Django server with python manage.py runserver and login to the Django admin at http://127.0.0.1:8000/admin/. You should see the admin’s login screen:

Click on the link for + Add next to Posts. Enter in the simple text Hello world!.

On 'save' you'll see the following page.

Now add our views file.

Create a posts.html template file.

And add the code below to simply output all posts in the database.

Finally, we need to update our urls.py files. Start with the project-level one located at myproject/urls.py.

Then create a urls.py file in the posts app.

And populate it as follows.

Okay, phew! We're done. Start up the local server python manage.py runserver and navigate to our new message board page at http://127.0.0.1:8000/posts.

It simply displays our single post entry. Time for tests!

TestCase

TestCase is the most common class for writing tests in Django. It allows us to mock queries to the database.

Let's test out our Post database model.

With TestCase the Django test runner will create a sample test database just for our tests. Here we've populated it with the text 'just a test'.

In the first test we confirm that the test entry has the primary id of 1 and the content matches. Then in the second test on the view we confirm that that it uses the url name posts, has a 200 HTTP response status code, contains the correct text, and uses the correct template.

Run the new test to confirm everything works.

Next Steps

There is far more testing-wise that can be added to a Django project. A short list includes:

• Continuous Integration: automatically run all tests whenever a new commit is made, which can be done using Github Actions or a service like Travis CI.
• pytest: pytest is the most popular enhancement to Django and Python's built-in testing tools, allowing for more repeatable tests and a heavy use of fixtures.
• coverage: With coverage.py you can have a rough overview of a project's total test coverage.
• Integration tests: useful for testing the flow of a website, such as authentication or perhaps even payments that rely on a 3rd party.

I'm working on a future course on advanced Django testing so make sure to sign up for the LearnDjango newsletter below to be notified when it's ready.

If you need more testing help now, an excellent course is Test-Driven Development with Django, Django REST Framework, and Docker by my friend Michael Herman.

Django Nose Test Runner

The author selected the Open Internet/Free Speech Fund to receive a donation as part of the Write for DOnations program.

Introduction

It is nearly impossible to build websites that work perfectly the first time without errors. For that reason, you need to test your web application to find these errors and work on them proactively. In order to improve the efficiency of tests, it is common to break down testing into units that test specific functionalities of the web application. This practice is called unit testing. It makes it easier to detect errors because the tests focus on small parts (units) of your project independently from other parts.

Testing a website can be a complex task to undertake because it is made up of several layers of logic like handling HTTP requests, form validation, and rendering templates. However Django provides a set of tools that makes testing your web application seamless. In Django, the preferred way to write tests is to use the Python unittest module, although it is possible to use other testing frameworks.

In this tutorial, you will set up a test suite in your Django project and write unit tests for the models and views in your application. You will run these tests, analyze their results, and learn how to find the causes of failing tests.

Prerequisites

Before beginning this tutorial, you’ll need the following:

• Django installed on your server with a programming environment set up. To do this, you can follow one of our How To Install the Django Web Framework and Set Up a Programming Environment tutorials.
• A Django project created with models and views. In this tutorial, we have followed the project from our Django Development tutorial series.

Step 1 — Adding a Test Suite to Your Django Application

A test suite in Django is a collection of all the test cases in all the apps in your project. To make it possible for the Django testing utility to discover the test cases you have, you write the test cases in scripts whose names begin with test. In this step, you’ll create the directory structure and files for your test suite, and create an empty test case in it.

If you followed the Django Development tutorial series, you’ll have a Django app called blogsite.

Let’s create a folder to hold all our testing scripts. First, activate the virtual environment:

Then navigate to the blogsite app directory, the folder that contains the models.py and views.py files, and then create a new folder called tests:

Next, you’ll turn this folder into a Python package, so add an __init__.py file:

You’ll now add a file for testing your models and another for testing your views:

Finally, you will create an empty test case in test_models.py. You will need to import the Django TestCase class and make it a super class of your own test case class. Later on, you will add methods to this test case to test the logic in your models. Open the file test_models.py:

Now add the following code to the file:

You’ve now successfully added a test suite to the blogsite app. Next, you will fill out the details of the empty model test case you created here.

Step 2 — Testing Your Python Code

In this step, you will test the logic of the code written in the models.py file. In particular, you will be testing the save method of the Post model to ensure it creates the correct slug of a post’s title when called.

Let’s begin by looking at the code you already have in your models.py file for the save method of the Post model:

You’ll see the following:

We can see that it checks whether the post about to be saved has a slug value, and if not, calls slugify to create a slug value for it. This is the type of logic you might want to test to ensure that slugs are actually created when saving a post.

Close the file.

To test this, go back to test_models.py:

Then update it to the following, adding in the highlighted portions:

This new method test_post_has_slug creates a new post with the title 'My first post' and then gives the post an author and saves the post. After this, using the assertEqual method from the Python unittest module, it checks whether the slug for the post is correct. The assertEqual method checks whether the two arguments passed to it are equal as determined by the ' operator and raises an error if they are not.

Save and exit test_models.py.

This is an example of what can be tested. The more logic you add to your project, the more there is to test. If you add more logic to the save method or create new methods for the Post model, you would want to add more tests here. You can add them to the test_post_has_slug method or create new test methods, but their names must begin with test.

You have successfully created a test case for the Post model where you asserted that slugs are correctly created after saving. In the next step, you will write a test case to test views.

Step 3 — Using Django’s Test Client

In this step, you will write a test case that tests a view using the Django test client. The test client is a Python class that acts as a dummy web browser, allowing you to test your views and interact with your Django application the same way a user would. You can access the test client by referring to self.client in your test methods. For example, let us create a test case in test_views.py. First, open the test_views.py file:

Then add the following:

The ViewsTestCase contains a test_index_loads_properly method that uses the Django test client to visit the index page of the website (http://your_server_ip:8000, where your_server_ip is the IP address of the server you are using). Then the test method checks whether the response has a status code of 200, which means the page responded without any errors. As a result you can be sure that when the user visits, it will respond without errors too.

Apart from the status code, you can read about other properties of the test client response you can test in the Django Documentation Testing Responses page.

Django Test Runner Pytest

In this step, you created a test case for testing that the view rendering the index page works without errors. There are now two test cases in your test suite. In the next step you will run them to see their results.

Step 4 — Running Your Tests

Now that you have finished building a suite of tests for the project, it is time to execute these tests and see their results. To run the tests, navigate to the blog folder (containing the application’s manage.py file):

Then run them with:

You’ll see output similar to the following in your terminal:

Django Test Client

In this output, there are two dots .., each of which represents a passed test case. Now you’ll modify test_views.py to trigger a failing test. First open the file with:

Then change the highlighted code to:

Here you have changed the status code from 200 to 404. Now run the test again from your directory with manage.py:

You’ll see the following output:

You see that there is a descriptive failure message that tells you the script, test case, and method that failed. It also tells you the cause of the failure, the status code not being equal to 404 in this case, with the message AssertionError: 200 != 404. The AssertionError here is raised at the highlighted line of code in the test_views.py file:

It tells you that the assertion is false, that is, the response status code (200) is not what was expected (404). Preceding the failure message, you can see that the two dots .. have now changed to .F, which tells you that the first test case passed while the second didn’t.

Conclusion

In this tutorial, you created a test suite in your Django project, added test cases to test model and view logic, learned how to run tests, and analyzed the test output. As a next step, you can create new test scripts for Python code not in models.py and views.py.

Following are some articles that may prove helpful when building and testing websites with Django:

Django Transactiontestcase

• The Django Unit Tests documentation
• The Scaling Django tutorial series

You can also check out our Django topic page for further tutorials and projects.