As Simon Willison mentions in his [Debugging Django](http://simonwillison.net/2008/May/22/debugging/) presentation, using the Test Client in the interpreter can be a great way to take a peek at the raw results from a view. In some cases you may need to add additional headers to the request (for instance a piece of middleware may rely on them).
Though it is not mentioned in the reference documentation, a quick peek at the code confirmed my hopes that it would be possible to add data to the request. The Client *get* and *post* methods both accept an **extra** kwargs parameter that allow you to populate the request with additional data.
Django's test client is very limited when it comes to testing complex interactions e.g. forms with hidden or persisted values etc. Twill excels in this area, and thankfully it is very easy to integrate it.
* Use `twill_setup` in your `TestCaseSubClass.setUp()` method
* Use `twill_teardown` in `TestCaseSubClass.tearDown()` method
* In a test, use something like `make_twill_url()` to generate URLs that will work for twill.
* Use `twill.commands.go()` etc. to control twill, or use `twill.execute_string()` or `twill.execute_script()`.
* Add `twill.set_output(StringIO())` to suppress twill output
* If you want to write half the test, then use twill interactively to write the rest as a twill script, use the example in `unfinished_test()`
Twill will raise exceptions if commands fail. This means you will get 'E' for error, rather than 'F' for fail in the test output. If necessary, it wouldn't be hard to wrap the twill commands to flag failure with TestCase.assert_
There are, of course, more advanced ways of using these functions (e.g. a mixin that does the setup/teardown for you), but the basic functions needed are here.
See also:
* [Twill](http://twill.idyll.org/)
* [Twill Python API](http://twill.idyll.org/python-api.html)
[zope.testing](http://pypi.python.org/pypi/zope.testing/) is a test framework and test runner, similar to the django test runner and nose.
This snippet is a [Layer](http://pypi.python.org/pypi/zope.testing/3.5.1#layers) class which you can assign as a layer attribute of your test suite to initialise and clean up the django test environment appropriately and to reset the test database between tests.
for example:
tests/suite.py
import unittest
from zope.testing import doctest
def test_suite():
suite = doctest.DocFileSuite("models.txt")
suite.layer = DjangoLayer
return suite
runtests.py
import os
from zope.testing import testrunner
os.environ['DJANGO_SETTINGS_MODULE'] = 'project.settings'
defaults = [
'--path', 'tests',
'--tests-pattern', '^suite$',
'-c'
]
testrunner.run(defaults)
**Note**: The `--failfast` argument in Django since version 1.2 does this. Use this snippet for earlier versions.
If a large number of your unit tests get "out of sync", it's often annoying to scan through a large number of test failures which overflow the terminal window's scroll buffer.
This library strictly stops after the first failure in a doctest suite. If you're testing multiple applications, it also stops after the first test suite with failures in it. So effectively you'll get one failure at a time.
This code has been tested with doctests only so far. You can also fetch the latest source from [my repository](http://trac.ambitone.com/ambidjangolib/browser/trunk/test/).
If you want to test a post request to a form, you need to give all input
fields, even if you just want to test if one value gets changed.
This snippets parses the HTML of a view and gives you a dictionary that
you can give to django.test.Client.
I hate when my unittest hits database. Especially when each test case needs different dataset.
So I wrote this db mock, that's local to specific test and uses sqlite3 in-memory db.
Usage (nosetests):
class TestMainNoData(DbMock):
'testing main function with no meaningful data'
def test_no_posts(self):
'there are no posts'
assert models.Post.objects.count() == 0, 'should be no feeds'
I use these helper methods in my unit tests. They turn many simple getting-and-posting tests into one-liners. Definitely a work in progress, and I can't be the only person who has done this sort of thing -- comments are more than welcome.
I'm posting this here mostly because I need a more permanent home for this than my lappy's hard drive. I hope it's interesting to other people, though.
Anyway - this script is what I use to test Django against multiple versions of Python and multiple databases. To actually run this you'll of course need Python 2.3, 2.4, and 2.5 installed along with MySQL, PostgreSQL, and sqlite3 -- and the associated database wrappers for all 3 Pythons.
Yes, for the record, I've got all those things installed on my laptop.
If you can somehow make that work, though, running this script will print out a nice little summary of what's failing against which versions of Python and which database. Run with `-v` to see the actual failures.