Like all mature programming languages, Django provides inbuilt unit testing capabilities. Unit testing is a software testing process where individual units of a software application are tested to ensure they do what they are expected to do.
Unit testing can be performed at multiple levels – from testing an individual method to see if it returns the right value and how it handles invalid data, up to testing a whole suite of methods to ensure a sequence of user inputs leads to the desired results.
Unit testing is based on four fundamental concepts:
Software testing is a deep and detailed subject and this chapter should be considered to be only a bare introduction to unit testing. There are a large number of resources on the Internet on software testing theory and methods and I encourage you to do your own research on this important topic. For a more detailed discussion on Django’s approach to unit testing, see the Django Project website.
You have been testing code right throughout this book; maybe without even realizing it. Each time you use the Django shell to see if a function works, or to see what output you get for a given input,
you are testing your code. For example, back in Chapter 2 we passed a string to a view that expected an integer to generate a
Testing is a normal part of application development, however what’s different in automated tests is that the testing work is done for you by the system. You create a set of tests once, and then as you make changes to your app, you can check that your code still works as you originally intended, without having to perform time consuming manual testing.
If creating simple applications like those in this book is the last bit of Django programming you do, then true, you don’t need to know how to create automated tests. But, if you wish to become a professional programmer and/or work on more complex projects, you need to know how to create automated tests.
Creating automated tests will:
There are many ways to approach writing tests. Some programmers follow a discipline called “test-driven development”; they actually write their tests before they write their code. This might seem counter-intuitive, but in fact it’s similar to what most people will often do anyway: they describe a problem, then create some code to solve it.
Test-driven development simply formalizes the problem in a Python test case. More often, a newcomer to testing will create some code and later decide that it should have some tests. Perhaps it would have been better to write some tests earlier, but it’s never too late to get started.
To create your first test, let’s introduce a bug into your Book model.
Say you have decided to create a custom method on your Book model to indicate whether the book has been published recently. Your Book model may look something like this:
First we have imported two new modules: Python’s
django.utils. We need these modules to be able to do calculations with dates. Then we have added a custom method to the
Book model called
recent_publication that works out what date it was 8 weeks ago and returns true if the publication date of the book is more recent.
So let’s jump to the interactive shell and test our new method:
So far so good, we have imported our book model and retrieved a book. Today is the 11th June, 2016 and I have entered the publication date of my book in the database as the 1st of May, which is less than 8 weeks ago, so the function correctly returns
Obviously, you will have to modify the publication date in your data so this exercise still works for you based on when you complete this exercise.
Now let’s see what happens if we set the publication date to a time in the future to, say, 1st September:
Oops! Something is clearly wrong here. You should be able to quickly see the error in the logic – any date after 8 weeks ago is going to return true, including dates in the future.
So, ignoring the fact that this is a rather contrived example, lets now create a test that exposes our faulty logic.
When you created your books app with Django’s
startapp command, it created a file called
tests.py in your app directory. This is where any tests for the books app should go. So let’s get right to it and write a test:
This should all be pretty straight forward as it’s nearly exactly what we did in the Django shell, the only real difference is that we now have encapsulated our test code in a class and created an assertion that tests our
recent_publication() method against a future date.
We will be covering test classes and the
assertEqual method in greater detail later in the chapter – for now we just want to look at how tests work at a very basic level before getting on to more complicated topics.
Now we have created our test, we need to run it. Fortunately, this is very easy to do, jump into your terminal and type:
After a moment, Django should print out something like this:
What happened is this:
manage.py test bookslooked for tests in the books application
test_recent_pubit created a Book instance whose
publication_datefield is 5 days in the future; and
assertEqual()method, it discovered that its
True, when it was supposed to return
That’s it for a very basic introduction to testing in Django. As I said at the beginning of the chapter, testing is a deep and detailed subject that is highly important to your career as a programmer. I can’t possibly cover all the facets of testing in a single chapter, so I encourage you to dig deeper into some of the resources mentioned in this chapter as well as the Django documentation.
For the remainder of the chapter, I will be going over the various testing tools Django puts at your disposal.