An Introduction to Django – Part 5

In this part, we will look further into testing (how to test views, using the test client, and general testing tips).

Testing Views

Previously, we wrote a test to make sure that our was_published_recently() method would return False if the publication date is in the future.  However, the view that shows the questions does not currently check the publication date.  We need to test the view to see how an end user would experience this problem.

The Django Test Client

Django provides you with a client that we can use in the shell or within the test.py file.  This client is used to simulate a user interacting with the code at the view level.  This is like programmatically clicking on links on your app and seeing what gets returned.

Open the shell (remember, navigate to your manage.py file then type the command “python manage.py shell” to open the shell).

Next we need to setup the test environment (note that doing it in the test.py file will differ slightly from this).  To do this, type:

The setup_test_environment() function installs a template renderer.  This will let us look at additional attributes on responses that otherwise wouldn’t be available.  This doesn’t, however, setup a test database.

Now, we need import the test client class:

This creates an instance of the client and it will let us do some work.  Try out some of these commands:

Fix our View

We don’t want the list of polls to show pols that aren’t yet published.  Open the polls/views.py file.  We want to update the get_queryset() method within the IndexView class.

Add the following import to the beginning of the file:

Next, update the get_queryset() method to be this:

Test The View

There are two ways we can test this.  First, we can load up the runserver and the site in our browser then add a new question with a publication date in the future to see if it will be displayed.  However, we might want to do this test many times in the future.  A better way to do this test is programmatically.

When I first ran these tests, I got an error that said

This occurred because I didn’t include the ‘polls’ namespace in the root urlconf file.  To fix this, open your /app/urls.py file (for me, this is /pantrio/urls.py) and change the line

to the following (so that it knows we are looking at the polls namespace):

We need to do this because in the /polls/urls.py file we added the lines:

Beyond that, the tests should run fine.

Other Items to Test

If you want to test your own ability to write tests and improve views, you can go through a similar methodology with the ResultsView.  You might also want to test to make sure that a Question  always has at least one (or maybe even at least two) Choice(s).

Is There Such A Thing as Too Much Testing?

There are many more things we can test.  Pretty soon, we might start to feel like we are writing more tests than actual code.  You might even start to worry that you are suffering from ‘test bloat’.  However, in general, since we pretty much write one test and then forget about it, it doesn’t matter if your list of tests grows.

That doesn’t mean, though, that your tests will never change.  As your code changes, you may find that you need to update your previous tests.  That’s okay, too.

Also, as your app and tests continue to grow, we might find that our tests are redundant.  Even this is okay – testing redundancy is typically a good thing.  A big idea to keep in mind is that we want our tests organized, since we know they will likely grow.  Some rules of thumb are to have:

  • a separate TestClass for each model or view
  • a separate test method for each set of conditions you want to test
  • test method names that describe their function and are easy to understand

Next time, we will look at updating the feel of our app.  I am getting really excited about trying to implement these ideas for my own application!

Have questions or suggestions?  Please feel free to comment below or contact me.

Leave a Reply

Your email address will not be published. Required fields are marked *