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 -~----------~----~----~----~------~----~------~--~---