In Chapter 1, Django Testing Overview, we begin development of a sample Django survey application. The example tests automatically generated by Django are described and run. All of the options available for running tests are covered.

In Chapter 2, Does This Code Work? Doctests in Depth, the models used by the sample application are developed. Using doctests to test models is illustrated by example. The pros and cons of doctests are discussed. Specific caveats for using doctests with Django applications are presented.

In Chapter 3, Testing 1, 2, 3: Basic Unit Testing, the doctests implemented in the previous chapter are re-implemented as unit tests and assessed in light of the pros, cons, and caveats of doctests discussed in the previous chapter. Additional tests are developed that need to make use of test data. Using fixture files to load such data is demonstrated. In addition, some tests where fixture files are inappropriate for test data are developed.

In Chapter 4, Getting Fancier: Django Unit Test Extensions, we begin to write the views that serve up web pages for the application. The number of tests is starting to become significant, so this chapter begins by showing how to replace use of a single tests.py file for tests with a tests directory, so that tests may be kept well-organized. Then, tests for views are developed that illustrate how unit test extensions provided by Django simplify the task of testing web applications. Testing form behavior is demonstrated by development of a test for an admin customization made in this chapter.

Chapter 5, Filling in the Blanks: Integrating Django and Other Test Tools, shows how Django supports integration of other test tools into its framework. Two examples are presented. The first illustrates how an add-on application can be used to generate test coverage information while the second demonstrates how use of the twill test tool (which allows for much easier testing of form behavior) can be integrated into Django application tests.

Chapter 6, Django Debugging Overview, provides an introduction to the topic of debugging Django applications. All of the settings relevant for debugging are described. Debug error pages are introduced. The database query history maintained by Django when debugging is turned on is described, as well as features of the development server that aid in debugging. Finally, the handling of errors that occur during production (when debug is off) is detailed, and all the settings necessary to ensure that information about such errors is captured and sent to the appropriate people are mentioned.

In Chapter 7, When the Wheels Fall Off: Understanding a Django Debug Page, development of the sample application continues, making some typical mistakes along the way. These mistakes result in Django debug pages. All of the information available on these pages is described, and guidance on what pieces are likely most helpful to look at in what situations is given. Several different kinds of debug pages are encountered and discussed in depth.

Chapter 8, When Problems Hide: Getting More Information, focuses on how to get more information about how code is behaving in cases where a problem doesn't result in a debug error page. It walks through the development of a template tag to embed the query history for a view in the rendered page, and then shows how the Django debug toolbar can be used to get the same information, in addition to much more. Finally, some logging utilities are developed.

Chapter 9, When You Don't Even Know What to Log: Using Debuggers, walks through examples of using the Python debugger (pdb) to track down what is going wrong in cases where no debug page appears and even logging isn't helpful. All of the most useful pdb commands are illustrated by example. In addition, we see how pdb can be used to ensure correct code behavior for code that is subject to multi-process race conditions.

Chapter 10, When All Else Fails: Getting Outside Help, describes what to do when none of the techniques covered so far have solved a problem. Possibly, it is a bug in external code: tips are given on how to search to see if others have experienced the same and if there are any fixes available. Possibly it's a bug in our code or a misunderstanding about how some things work; avenues for asking questions and tips on writing good questions are included.

In Chapter 11, When it's Time to Go Live: Moving to Production, we move the sample application into production, using Apache and mod_wsgi instead of the development server. Several of the most common problems encountered during this step are covered. In addition, the option of using Apache with mod_wsgi during development is discussed.

You will need a computer running a Django 1.1 release—the latest 1.1.X release is recommended. You will also need an editor to edit code files and a web browser. You may choose to use whatever operating system, editing, and browsing tools you are most comfortable with, so long as you choose an operating system that can run Django. For more information on Django's requirements, consult http://docs.djangoproject.com/en/1.1/intro/install/.

For your reference, the example console output and screenshots in this book are all taken from a machine running:

You can use any database supported by Django. For illustration purposes, different databases (SQLite, MySQL, PostgreSQL) are used at different points in the book. You will likely prefer to choose one to use throughout.

Additional software is used at specific points in the book. Wherever a software package is introduced, notes on where to obtain it for installation are included. For your reference, the following is a list of additional software packages and the versions used in the book:

Note that you do not need to have any of these additional packages installed when you start working through this book, they can each be added at the specific point where you want to start using them. The versions listed are those used for the output shown in the book; it is expected that later versions will work as well, though the output produced may be slightly different if you use a newer version.

If you are a Django application developer who wants to create robust applications quickly that work well and are easy to maintain in the long term, this book is for you. This book is the right pick if you want to be smartly tutored to make best use of Django's rich testing and debugging support and make development an effortless task.

Basic knowledge of Python, Django, and the overall structure of a database-driven web application is assumed. However, the code samples are fully explained so that even beginners who are new to the area can learn a great deal from this book. If you are new to Django, it is recommended that you work through the online Django tutorial before beginning this book.

In this book, you will find a number of styles of text that distinguish between different kinds of information. Here are some examples of these styles, and an explanation of their meaning.

Code words in text are shown as follows: "Now we have the basic skeleton of a Django project and application: A settings.py file, a urls.py file, the manage.py utility, and a survey directory containing .py files for models, views, and tests."

A block of code is set as follows:

__test__ = {"doctest": """
Another way to test that 1 + 1 is equal to 2.

>>> 1 + 1 == 2
True
"""}

When we wish to draw your attention to a particular part of a code block, the relevant lines or items are set in bold:

urlpatterns = patterns('', 
    # Example: 
    # (r'^marketr/', include('marketr.foo.urls')), 

    # Uncomment the admin/doc line below and add # 'django.contrib.admindocs' 
    # to INSTALLED_APPS to enable admin documentation: 
    # (r'^admin/doc/', include('django.contrib.admindocs.urls')), 

    # Uncomment the next line to enable the admin: 
    (r'^admin/', include(admin.site.urls)), 
    (r'', include('survey.urls')), 
) 

Any command-line input or output is written as follows:

kmt@lbox:/dj_projects$ django-admin.py startproject marketr

New terms and important words are shown in bold. Words that you see on the screen, in menus or dialog boxes for example, appear in the text like this: "This drop-down box contains a full list of the ticket attributes we could search on, such as Reporter, Owner, Status, and Component."

Feedback from our readers is always welcome. Let us know what you think about this book—what you liked or may have disliked. Reader feedback is important for us to develop titles that you really get the most out of.

To send us general feedback, simply send an e-mail to <[email protected]>, and mention the book title via the subject of your message.

If there is a book that you need and would like to see us publish, please send us a note in the SUGGEST A TITLE form on www.packtpub.com or e-mail <[email protected]>.

If there is a topic that you have expertise in and you are interested in either writing or contributing to a book on, see our author guide on www.packtpub.com/authors.

Now that you are the proud owner of a Packt book, we have a number of things to help you to get the most from your purchase.