Django 1.1 Testing and Debugging 26
johnmccollum writes "A wealth of tools are available to debug and test Django applications, but knowing when and how to use these resources can intimidate the new user. Django 1.1 Testing and Debugging, by Karen M. Tracey, aims to walk the user through the process of creating a web application from scratch, ensuring that the resulting code is bug-free and ready for production." Keep reading for the rest of John's review.
In a way, Django makes it deceptively easy to write a dynamic web application. With a few lines of code, you can have an fully functional application up and running in a short space of time, and complex applications take less time than ever to develop. Inevitably, though, bugs will creep in to the development process, and the professional developer will want to make sure that their application is as bug-free as possible before launching.| Django 1.1 Testing and Debugging | |
| author | Karen M. Tracey |
| pages | 409 |
| publisher | Packt Publishing |
| rating | 9/10 |
| reviewer | John McCollum |
| ISBN | 978-1-847197-56-6 |
| summary | Building rigorously tested and bug-free Django applications |
The book opens with a simple question: "How do you know when code you have written is working as intended?" The answer, of course, is that you test it. But if you're not a cowboy coder, you'll want to leverage the full power of Django's automated testing framework for best results. In the course of this book, the author develops a full web application, from start to finish, and describes how each section would be tested and debugged.
The author's intended audience for this book is perhaps one that is relatively new to Django. Ideally, the reader will have a functioning installation of Django, will have worked through at least the tutorial, and may well have written a couple of applications. This book would also be excellent for someone migrating to Python from another language, or moving into MVC frameworks for the first time. Crucially, the book doesn't just explain how to test, it also explains when and what to test too, so it serves as an ideal introduction into testing in general. There are many code examples and screenshots, and each line of code is fully explained.
The book kicks off with an examination of doctests and unit tests. Their relative pros and cons are explained in some depth, and the author does a great job in this section of discussing exactly what you should be testing, initially beginning with data models. She then moves on to more advanced unit testing strategies and applications, such as testing views and customizations of the admin area.
One of Python's greatest strengths is its ecosystem, and the following chapters cover some of the other tools you might want to integrate into your project. Django-coverage provides reporting on how much of your code is covered by tests, and Twill is a package that essentially replaces Django's test client to provide enhanced functionality — particularly for working with forms. Both packages have fully explained and in-depth examples to work through. (Code downloads are available at Packt Publishing's web site for the terminally lazy!)
With the testing section of the book complete, the author moves on to the debugging section of the book. Starting with the very basics (setting up Django in debug mode), the book then takes a detailed look at the Django debug page. This is something that I could see being useful for many new users — the debug page contains a wealth of information (and not all of it is always entirely relevant, if not outright misleading), so learning to understand this page is crucial to your success as a Djangonaut.
The book then takes a tour of the excellent django-debug-toolbar, before moving on to what was, for me, the most valuable chapter of the book: "When you don't know even know what to log: Using Debuggers." This chapter introduces the PDB (Python Debugger) library.
Like many others, I suppose, Django was my first introduction to Python. For that reason, my knowledge of the standard library is perhaps not as strong as it could be. For me, learning about the different ways of using the debugger was the highlight of the book, and something that will probably change the way I develop with Django.
The book concludes, of course, by taking the application into a production environment. And in line with the latest advice, that means setting up the site using Apache and mod_wsgi. In keeping with the theme of the book, the most common issues in deployment are identified and resolved.
This book weighs in at over four hundred pages, and its greatest strength is its wide scope. Although the basics of testing in Django are easy to understand, it's another thing entirely to see an entire application built from the ground up with testing at the forefront. As I mentioned before, the focus is as much on developing a testing and debugging strategy as it is on the technical aspects.
From a more technical point of view, the subject matter ranges from beginner to advanced. From writing the most basic doctests to debugging multi-process race conditions, the difficulty level increases incrementally, and no important details are skirted over. The prose is well-written and easy to read throughout.
If I had one gripe about the book, it would be that in places, it goes into a little too much detail. There's a section on using the Django web site (the bug tracker, the mailing list etc.) that I could have done without entirely. Although it might be useful for some users, the site is pretty self-explanatory and doesn't really warrant the attention it gets, in my opinion.
You shouldn't let that put you off though — this really is an excellent exploration of the topic. In addition, Packt Publishing will make a donation to the Django project for every book sold, so in purchasing this book, you'll be indirectly helping the project financially too.
This book is worth a place on any Django developer's bookshelf.
You can purchase Django 1.1 Testing and Debugging from amazon.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.
I hope... (Score:2, Funny)
Re: (Score:3, Insightful)
Because Slashdot can't be rewritten from the ground up every time the Next Big Thing comes along.
Re: (Score:2, Interesting)
In a sense, it is. We can basically consider Perl as an unrefined version of Python. Much of the Slash codebase implements the same patterns that we see in Django, but did it a decade earlier. The differences are actually quite minimal.
Re: (Score:2)
Django is about packaging an ORM, templating system, and URL dispatching based on regular expression matching. If slashdot doesn't use an object relational mapper or a templating system, then its probably more like web.py
Re: (Score:3, Interesting)
Replace problem components with corrected components built using the desired platform. With as buggy as slashcode seems to be, eventually they'll have replaced almost all of it (and why would you bother to replace the parts that don't have issues?).
The trick is to get components to play nicely with components on the other platform until you can consolidate on the final(?) platform.
Re: (Score:1, Insightful)
You must be a manager who doesn't get his hands dirty doing actual coding.
Anyone who actually works with software knows that the idea of "reusable components" is a load of bullshit. Libraries are about as close as you'll ever get to that, but even those aren't really "components".
The only people who think software can be built by out of these "components" are people who have never tried to develop software.
Re: (Score:3, Interesting)
You must be a manager who doesn't get his hands dirty doing actual coding.
I'm not a manager. I write code for a living (or help others write code, depending on what hat I'm wearing).
Anyone who actually works with software knows that the idea of "reusable components" is a load of bullshit. Libraries are about as close as you'll ever get to that, but even those aren't really "components".
I didn't say "reuse components", I said "replace components". Maybe the word "component" has special meaning to you, but around here, a component is any chunk of code that can be treated as a black box by the rest of the code. Replace the internals with whatever you like as long as the inputs and outputs are unchanged.
I also never said it would be easy. The difficulty is entirely determined by the con
Re: (Score:2)
Anyone who actually works with software knows that the idea of "reusable components" is a load of bullshit
Most of my Django projects use reusable components. It's one of the reasons I use Django.
Already obsolete (Score:2, Interesting)
Re: (Score:2)
Actually this is happening with a lot of books, which in turn, annoy the readers which expect a more accurate information than the readmes or the wikis (more if you're a total beginner in the subject.)
The only solution is an updatable e-book that catches with the latest version (for, say, six months from published), or some (more expensive) policy of returning and getting an updated hardcopy version.
If software stores offer updates for the next X years, why not do the same for books, specially for the compu
Re: (Score:2)
Re: (Score:2)
True. But how many folks are likely to buy a 400+ page book at technical book prices that is out of date at purchase? At the very least they could have been smart enough to just call it "Django Testing and Debugging", keep most of the content the same and just mention that it covers both Django 1.1 and 1.2 but might be missing a few bits that apply to the latter. Given the pace at which OSS software moves, putting a version number in the title just indicates that the author does not understand that essen
Re: (Score:2)
I learned django with "Practical Django Projects" when it first came out. Even that book was obsolete to the point that you couldn't get through the book. I actually had to learn the obsoleted version because I ran into a wall every chapter. After learning it I had to learn what changed in version 1.0
Hint (Score:5, Insightful)
(Though honestly, I'm surprised people buy this category of book at all anymore -- it's often fast and free to find plenty of how-tos, reference, and example material for your poison of choice online.)
Re: (Score:1, Interesting)
Hint: if you're targeting a specific version of a framework in your book, especially when that framework has a release cycle of less than a year, don't bother. I'm surprised the reviewer bothered wasting money on the copy.
Books don't become obsolete with point releases of the Django 1.x series.
One of the outstanding things about Django and its team of developers and community is their well reasoned approach to maintaining compatibility between point releases. The have written, well defined policies for compatibility.
Django 1.2 is a fantastic release with features like multiple databases and faster testing that provide great benefits, but all my code for 1.1 still works.
The developers are protective of trunk--you can sanely
Bug Free Code with Product X (Score:1)
Now their credibility with me is all shot to shoot. ;P
Debug Django how-to? Use Eclipse! (Score:1, Interesting)
It is pretty easy to get Django running under Eclipse for debugging purposes.