Order(n) is a pretty bad idea. Originally, my SearchIndexes for Haystack looked a bit like this: class RegularEventIndex(indexes.SearchIndex): text = indexes.CharField(document=True, use_template=True) Then, when someone ran a search, and I wanted to display a result, I’d load up a template (which template I loaded depended on grabbing the model name, as recommended in the docs), and any attributes of the model I wanted to display required doing a database lookup to fetch the data, like this:

A long while ago, I discovered that running Django tests is much faster if you use SQLite, and if you turn off South (this now seems pretty obvious, but at the time was a bit of a revelation to me). Since then, I’ve come across a better way of setting this up, to avoid having a test_settings.py: # If manage.py test was called, use SQLite import sys if 'test' in sys.

I came across Travis CI this week, and it’s awesome. I’ve got a bunch of tests for django-magazine, but I’m not very good at running them. It turns out that unit tests aren’t very useful if you don’t run them, so I wanted to make sure that every time I pushed code to it, the tests run. Enter Travis CI. Easy Unit Testing for Reusable Apps django-magazine is a reusable app - that is, it doesn’t ship with settings files, so you can’t run its tests just after installing it[1.

See, I know nothing! — Manuel I distinctly remember being 17 years old, I’d just finished re-launching a site for a charity I was involved with1, and I confidently declared that I knew all there was to know about building websites. And I believed it. At the time, I was building sites in PHP, and like every other 17 year-old learning PHP, I’d built entirely my own system for managing the site.

I started with unit testing about 4 years ago. I started writing what were probably integration tests, when I was working on the database backend of our application. The tests I wrote were designed to make sure that our process which saved data actually saved data. Saving data involved creating a document, calling save on it, which would save it in the file system-based database, which would hit the file system.

In about 1998, I was building a website for a friend. The site was entirely static. I’d already learned the hard way about the pain of trying to keep lots of separate static HTML files visually consistent. To build the site, I used a system (whose name has since faded from memory) which took as its input some template files, some files containing the content, and combined them together to build a website.

Every once in a while, I want to start again. I currently have 6 different sites using Kaléo, a bit of software I wrote for managing Church websites, which I’ll write about another time. The code is stored in a private git repository, and synced out to 6 different places every time I need to make a change. Most these changes are fairly simple, and upgrading each site looks roughly like this:

I’d basically given up on attempting test-driven with Django, given the project I’m currently working on uses models with a lot of South migrations. Just building the database and running the migrations could take a minute or so when running manage.py test, and resetting the database to a clean state meant the test suite would take several minutes to run. I’ve had an idea in the back of my mind for a while, and today I finally got around to making it work.