Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Django 1.1 Testing and Debugging

samzenpus posted more than 4 years ago | from the read-all-about-it dept.

Books 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.

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.

cancel ×

26 comments

Sorry! There are no comments related to the filter you selected.

It's like XKCD on roids! (-1, Troll)

Anonymous Coward | more than 4 years ago | (#32350146)

It's totally awesome: http://goatkcd.com/744/ [goatkcd.com]

Frameworks are lame (-1, Troll)

Anonymous Coward | more than 4 years ago | (#32350334)

See title.

GAWD I LUV DJANGO !!!! (-1, Troll)

Anonymous Coward | more than 4 years ago | (#32350512)

I think is a good book. Buy it now and then read it soon. You are better for doing as I tell you.

Chopstick Luver

The name django sounds familiar... (-1, Offtopic)

Anonymous Coward | more than 4 years ago | (#32350594)

Isn't django the name of a gay bathhouse in Cupertino that apple employees hang out at?

sexy sausage (-1, Troll)

Anonymous Coward | more than 4 years ago | (#32350608)

nt

Obvious question (-1, Troll)

Locke2005 (849178) | more than 4 years ago | (#32350650)

If Django is so great, why isn't slashdot implemented in Django?

Re:Obvious question (3, Insightful)

ebh (116526) | more than 4 years ago | (#32350684)

Because Slashdot can't be rewritten from the ground up every time the Next Big Thing comes along.

Re:Obvious question (2, Interesting)

Anonymous Coward | more than 4 years ago | (#32350692)

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:Obvious question (1)

FunkyELF (609131) | more than 4 years ago | (#32362396)

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:Obvious question (0)

Anonymous Coward | more than 4 years ago | (#32350698)

slashdot was written a very long time ago in perl, because that's all the knew about. Why rewrite something that (almost) works just for the sake of it?

Re:Obvious question (2, Interesting)

Dan Ost (415913) | more than 4 years ago | (#32350894)

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:Obvious question (1, Insightful)

Anonymous Coward | more than 4 years ago | (#32351034)

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:Obvious question (2, Interesting)

Dan Ost (415913) | more than 4 years ago | (#32351248)

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 constraints of the current implementation and the constraints imposed by the new implementation.

Re:Obvious question (1)

mweather (1089505) | more than 4 years ago | (#32351632)

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.

Re:Obvious question (0)

Anonymous Coward | more than 4 years ago | (#32364872)

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".

You're the reason everything gets reinvented from the ground up every time a new project comes along.

You're really not as good as you think you are. If you worked with your team to help develop libraries (components being a special case of that with a standard interface), instead of cowboy coding, then maybe all these projects that are over time, over budget, or conversely with heisenbugs galore, wouldn't be. The people who have to use your stinkin' bloatware would thank you.

Already obsolete (2, Interesting)

Goodgerster (904325) | more than 4 years ago | (#32350770)

Really, did the publishers not notice the months and months of version 1.2 betas/release candidates? It's an impressive trick of scheduling to have a book on 1.1 released on practically the same week as 1.2.

Re:Already obsolete (0)

Anonymous Coward | more than 4 years ago | (#32350878)

I've got a great idea. Let's write a dead tree on the assumption that the beta will be accurate, even though it takes several weeks to go through publishing, printing and distribution.

Re:Already obsolete (1)

DiegoBravo (324012) | more than 4 years ago | (#32351154)

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 computing related ones?

Re:Already obsolete (1)

0racle (667029) | more than 4 years ago | (#32350988)

For the most part, everything in the book will work with a project created from scratch targeting Django 1.2.

Re:Already obsolete (1)

c0d3g33k (102699) | more than 4 years ago | (#32351144)

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 essential fact - raising the question of what else did they miss?

Re:Already obsolete (1)

FunkyELF (609131) | more than 4 years ago | (#32362446)

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 (4, Insightful)

thePowerOfGrayskull (905905) | more than 4 years ago | (#32351204)

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.

(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:Hint (1, Interesting)

Anonymous Coward | more than 4 years ago | (#32364264)

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 run testing servers directly off it to see how proposed changes will affect your code for months ahead of a stable release.

Bug Free Code with Product X (1)

Unka Willbur (1771596) | more than 4 years ago | (#32351382)

"...ensuring that the resulting code is bug-free and ready for production."

Now their credibility with me is all shot to shoot. ;P

Debug Django how-to? Use Eclipse! (1, Interesting)

Anonymous Coward | more than 4 years ago | (#32351946)

It is pretty easy to get Django running under Eclipse for debugging purposes.

Check for New Comments
Slashdot Login

Need an Account?

Forgot your password?

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>