I want to begin integrating unit tests into my Django projects and I\'ve discovered unit testing a view to be tricky because of the way Django implements views with functions. <
I'm not sure how testing a view is tricky.
You just use the test client.
Code coverage is easy. You reason how how a URL request maps to a code path and make the appropriate URL requests.
You can, if you want, call the view functions "manually" by creating a Request object and examining the Response object, but this is too much work.
If you have doubts about your code coverage, that's a good thing. It means you have code you can't easily map to a URL (which is all a user can ever see of a web application.) If you have code that doesn't map to a URL, you should probably either (a) delete the code or (b) refactor it into a separate module.
We have lots of modules outside our view functions. Our view functions import these modules. We test these "outside the view function" modules with ordinary unittest.
Here's a typical structure.
some_big_product/
|-- __init__.py
|-- settings.py
|-- urls.py
|-- logging.ini
|-- other_global_files.py
|-- an_app_1/
| |-- __init__.py
| |-- urls.py
| |-- models.py
| |-- views.py
| |-- tests.py <-- the generic Django testing
| |-- app_specific_module.py
| |-- app_specific_package/
| | |-- __init__.py
| |-- test_app_specific_module.py <-- unittest
| |-- test_app_specific_package.py
|-- generic_module.py
|-- generic_package/
| |-- __init__.py
|-- tests/
| |-- test_this.py
| |-- test_that.py
| |-- test_all.py <-- not always practical
|-- scripts/
|-- run_tests.sh
django.test.client should have everything you need for basic unit testing of the view. I also really like twill and selenium for testing the full stack.
You could try tddspry - collection of helpers to test Django with nosetests and twill. Nose also have coverage plugin which generate pretty reports of the coverage.