Changes between Version 10 and Version 11 of TestingGuide

04/11/09 05:38:12 (6 years ago)



  • TestingGuide

    v10 v11  
    1 = Django Testing Guide =
    2 Testing web applications has historically been hard. It's even harder to write unit tests that work well when someone integrates your app. This guide aims to provide pointers and best practices for testing your apps and writing portable unit tests.
    4 Though there are multiple types of automated tests, this article deals with unit tests. Unit testing is often combined with test-driven development. This means you write your test first and then implement code to make the test pass. The basic workflow is:
    6 1. Write the test case[[BR]]
    7 2. Run the test case (to make sure it fails)[[BR]]
    8 3. Write the implementation code[[BR]]
    9 4. Run the test case (to make sure it passes)[[BR]]
    11 == Writing portable tests ==
    12 Portable tests, like portable software, are tests that will run properly regardless of how the and where the test code is executed. It could be your app will be ran standalone or integrated in a bigger project.
    14 === Write your views using classes instead of functions ===
    15 When you write your view as a class with a __call__ method. This offers a way to split the __call__ method into multiple methods while still showing that the methods belong to a specific view (and are only called by this view). If you choose to write a lot of functions which are not grouped by using a class stuff can get messy real fast.
    17 === tests should run in isolation ===
    18 Whenever possible use test_urls and dedicated test templates to make sure your tests run as isolated. Usually you will want to write your test in such a way that they will only fail when there a failure in what you're testing. What you don't want is your unit tests failing because someone decided to put a bad template tag in your non-test template.
    20 If at all possible you should avoid using Django's test client, too. Why? Because it often introduces failures which are not related to your code (e.g. middleware). If you're going to do anything more complex than getting or setting a variable in Django, write a method class to do that and test it directly. When you are using Django's test client you're actually writing integration tests instead of unit tests because you are not testing methods and functions in isolation but you're testing the framework as a whole.
    22 === tests should test one thing ===
    23 A good test tests one thing, not five or ten. If you have multiple tests that are almost the same, use the setUp method in your testcase to set things up.
    25 === test_urls ===
    26 Never use test_urls if your don't have a dedicated test template. Someone else may insert {% url %} tags in there (or template tags that do url reversing) causing your unit tests to fail.
    28 == Solving specific problems ==
    30 === Testing view classes ===
    31 Testing view classes through the test.client() can often require you to write lots of views that call the test class. It's often convenient to write a mapper view class that allows you to map a function to a temporary url.
    34 == Other pages about testing and django ==
    36 CookBookTestingTools describes test runners like nose
Back to Top