Note to Self 13 – Whole Lot of Django

• Testing Django can be somewhat challenging. Instead of simply running a unittest module, you need to run the manage.py script in your Django app passing it the “test” parameter. This sets up a test database for your model, runs your tests against that model and then destroys your database. In effect, it turns your unit tests into functional tests.
• Another item regarding testing that bothers me is the hoops you have to jump through in order to use a testing framework other than unittest. We want to use Nose for our project and getting it to run in the Django environment requires that we install a Django App (django-nose) in our Project, and then make a couple of changes in our project settings file. I admit it doesn’t sound too bad, but when you compare it to the ease of simply running “nosetest” the story is not nearly as compelling.
• Putting testing aside for the moment, the rest of Django has been a pretty good experience. Both the templating language and the models are simple to learn and start using right away. Even though Django favors configuration over convention, the amount of configuration necessary is relatively small and hasn’t been much of a burden.
• The main configuration hassle has been mapping urls. The process can be simple, but leaves the door open for something much more elaborate. This is one of those things where I wish they would looked closely at Rails and adopt some of their practices: use conventions until it configurations become necessary.
• Going back to the manage.py file for a moment, I should say there are some cool things that you can do here. For those Rails developers out there, some of the functionality of Rake is contained in manage.py though certainly not all of it. Though the most common use of manage.py is syncing the database with your model (syncdb) and starting your development server (runserver), I find the shell command to be extremely useful for test driving models I’ve created.
• Though not specifically Django related, I feel Nosy is worth mentioning. I’ve become addicted to this script (go here for the original post) written by Jeff Winkler a few years ago. Like many others, I’ve taken the original script and modified it suit the needs of my project. In short, Nosy is a script that runs Nose anytime a python file in a given directory changes. It’s essentially like having a mini-ci server running on your desktop. I’ve found it very freeing to simply write code and be instantly notified if something breaks. No switching windows to run a test.
• As I mentioned before, the testing story for Django is not ideal. But this doesn’t mean you can’t improve the situation. I’ve made sure that the code going into our views.py file (which interestingly enough is really a controller) as close to pure framework code as I can. Most of my complexity is stored in a separate module that can be easily tested with Nose. To allow for even better testing, I make sure that all of the methods in the extra module accept a model as a parameter making mocking the models possible.
• In summation, Django absolutely makes creating websites much easier. Though testing is challenging, you can improve upon it if you put some though into it. Would I recommend Django? If you’re already comfortable in Python, than absolutely. If not, I’m not so sure. Rails is a compelling option considering it’s preference of convention over configuration. Keep in mind the required configurations in Django are very obvious whereas “stepping off the Rails” in RoR takes a bit knowledge of the framework.