Hi,
Just a little teaser:
I've found a nice approach to test your views. The problem is, the http
response is hard to test, since you have to either scrape the interesting
content from it, or use regexps. Both is not really nice.
My approach does not check the actual http response, but the context that the
view passes to the template. This means:
- changes in the template don't affect your tests
- changes in the tests are much easier to handle than with screen scraping
- test cases are easy to read, since you see all the data passed in and out
During a test run:
- you need to insert a special template tag ("ContextKeeper") into your base
site template (see below)
- a HttpRequest gets created and run through Django via
BaseHandler.get_response()
- the ContextKeeper fetches the view context and saves it into thread storage
- this is then used to compare the context to the expected context.
- In the context, objects are replaced by their __repr__(), but lists,
dictionaries, sets, tuples stay as they are
- You can ignore context entries that you're not interested in, like all the
"LANGUAGE_*" entries
In code, it looks like this:
def test_portal_initial():
# test case for GET /mailadmin/portal/
response, context = runner.get_response('/mailadmin/portal/', 'GET', {}, {})
assert runner.check_context(response, context, {'domain_title': None,
'domains': [],
'get_new_mailbox_url': 'create-mailbox/',
'kunden': ['<Kunde: xxxxx>'],
'mailbox_count': 0L,
'mailboxes': [],
'mailrule_count': 1L,
'messages': [],
'person': '<Person: xx, Herr Martin H. X.>',
'rules': ['<Mailrule: (smtp_route_mx) xxxxx.de -> mx.xxxxx.de>'],
'single_kunde': True,
'too_many_domains': False,
'too_many_mailboxes': False,
'too_many_rules': False,
'user': '<User: mir>'})
assert runner.check_response(response, {'status_code': 200, 'cookies':
SimpleCookie('')})
This can the be used with py.test.
Then, there's a special middleware that writes the test cases for you while you
use the browser. For each http transaction, it creates a test case. Cut and
paste, a little bit tailoring and organizing, you're done.
I've also solved the problems of initializing the test database from a set of
dicts, comparing dictionaries etc., and handling sessions. I'm already using it
with great fun. It's only a little bit raw, but I plan to contribute it soon.
Then, I've found a way to combine py.test with doctests, including database
setup. I use this to test all the functions that are not views.
Michael
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-users
-~----------~----~----~----~------~----~------~--~---
