I’m continuously trying to get used to test driven development, as I agree with its many advantages cited around the web. Still, I often find it hard to come up with a necessary (and hopefully sufficient) list of tests. Moreover, as I often code for fun only, I don’t pay much attention to the question. This has changed now as I got a paying project. Here are my first insights, I hope it will help other django enthusiasts as well. :)

The bottom line is test every method you write, including output variables and inside logic. Moreover, write tests that pass as they mimick normal usage, and then start to think about tests that fail if someone tries abnormal usage (like setting a start date after an end date).

Testing models

The model contains your business logic and data. Something no user should be able to avoid or misuse. As django itself is thoroughly tested there is not much reason to test whether a NullBooleanField accepts None as a value, and in general I see no reason in testing a model’s attributes.

On the other hand every defined method should be tested! For example, if you have a model to represent Comments with approved and published attributes, in the save method you’ll likely avoid saving if approved==True and published==False. This is a logic to be tested. You should similarly check your get_absolute_url (and similar) methods whether they provide proper output.

class ComentModel(models.Model):
    author = models.ForeignKey(User)
    comment = models.CharField
    published = models.BooleanField
    approved = models.NullBooleanField

    def save(self, force_insert=False, force_update=False):
        if approved==True and published==False:
            return
        super(Submission, self).save(force_insert, force_update)

Testing forms

My feeling is that many people misunderstand the use of forms. Basically forms are to interact with non-trusted users (and sometimes to extend the admin functionality as well, but that’s a different story).

This being said, it might happen that you have the same functionality on the admin and on your main site, like adding a comment for something. The difference being that on the admin site the user can pretend to be any other user for example, or can immediately approve his comment. While on the main site the user can comment only under his own name, and every comment might need approval. Despite this difference, both comments will be stored in the same Model.

Moreover, every logic related to a bit complex data that will be stored in the database should be included in your form definition, instead of using your views. This for example allows you to easily reuse the same form processing in different views (e.g. APIs might need different views than simple HTML, but they will still process the same data).

As this is the point many posts miss, I’ll repeat it: when you would like to save data coming form users in a model rather keep your views simple, and make your forms complex, than having complex views and simple forms.

So, as we will have some hard-working form classes, what should we test? The same principle applies as before: test every method you define! If there is any reason to define your own __init__ method, then you should test the modified form properties as well.

For example, take a conference application. Every conference has many Topics, and if you want to present a paper you might need to select a Topic when you submit your idea. But the form should show only the topics for the conference you are interested in. This can be achieved by overwriting the __init__ method like this

class SubmissionForm(RegistrationForm):
    topic = forms.ModelChoiceField(label=_('Select a topic'), 
           queryset=models.Topic.objects.all(), empty_label=None,
           help_text=_('Topics help our reviewers to coordinate their work. \
            Please find a topic that best matches your paper'))

    def __init__(self, *args, **kwargs):
        super(SubmissionForm, self).__init__(*args, **kwargs)
        self.fields['topic'].queryset=\
            models.Conference.objects.get(pk=kwargs['initial']['conference']).topic_set.all()

In this case we should test that form.fields['topic'].queryset contains all the topics of the given conference, and only those.

Testing views

As you already know, you should check every method you define. Moreover, you should check that the methods you want to be restricted (e.g. by the @login_required decorator) are really restricted, but are available for authorised users. For more subtle restrictions, like showing only your own posts further testing is necessary, as this assumes that the user should be logged in, but still can’t see every post.

Moreover, if you are using forms like above that should be initialised, then you should check that they are indeed properly initialised. In the above case this would mean to check the template context variable for the form object, and see the value of response.context['myform'].initial.

Testing templates

As I am not a designer guy, I’ve found this is the easy part! Basically, I just test for the variables that the designers might need to put together the content of the page. Like this:

class TemplateTests(MyTestCase):

    def check_template_var(self, rsp, var):
        '''
        Check for template variable ``var`` in response rsp
        '''
        if isinstance(rsp.context, dict):
            contexts = [rsp.context,]
        else:
            contexts = rsp.context

        for c in contexts: 
            if c.has_key(var):
                return True
        return False        

    def test_conference_list_html(self):
        rsp = self.client.get(reverse('conference_list'))
        self.assertTrue(self.check_template_var(rsp, 'conference_list'),
                        "conference_list is not set for conference_list.html")

Other tests

It might happen that you write some custom template tags, filter, or some strange admin functionality. I haven’t thought much about testing these yet, but for template tags at least there are some posts on the web

Conclusion

The bottom line is to test every method you write, including output variables and inside logic.