When writing tests for [Django views](http://docs.djangoproject.com/en/dev/#the-view-layer), especially for projects at [work](http://www.ajc.com), I’ve almost completely abandoned any sort of detailed test for the template being rendered.
My tests usually look something like this:
def test_link_archive_should_show_published_links(self):
"""Links in draft status shouldn't appear in the archive."""
#create some data for testing, optionally use a fixture
l = Link(url="http://www.heisel.org/", title="Worst. Blog. Ever.", published=False)
l.save()
r = self.client.get("/links/archive/")
self.assertValidResponse(r)
self.assertContains(r, l.title, 0)
l.published = True
l.save()
r = self.client.get("/links/archive/")
self.assertValidResponse(r)
self.assertContains(r, l.title, 1)
It’s slightly heretical, I know. But you don’t want your test suite breaking because of a change in HTML, or a change in your [date format](http://docs.djangoproject.com/en/dev/ref/templates/builtins/#now), or the addition of new output, etc.
Those changes are frequently made far down the road from the initial launch (say during a [redesign](http://blogs.ajc.com/ajc/2009/01/13/weve-been-making-some-changes/)) when you’re likely not to remember why you tested for such fine grained output.
Since I’m generally [testing first](http://www.xprogramming.com/xpmag/testFirstGuidelines.htm) (and who isn’t?) I use the view test as a chance to figure out what information — no matter the whims of the designer, destiny or the sands of time — really has to be presented to the user for this view to fulfill it’s job.
Test for the presence of those strings and move on.
