On 7/13/06, Simon Willison <[EMAIL PROTECTED]> wrote:

The best way of running tests against a Django application, to my
mind, is to run a "fake" web server (i.e. one that doesn't actually
bind to a port) around the application.

Agreed; although I'm not sure that you actually need to run a server in the 'start a process/thread' sense. A TestHandler() that operates much like the mod_python or wsgi Handler objects (or a light wrapper around one of those handlers that provides a nice testing interface) should be sufficient.

There's just one problem with this approach: while running assertions
against an HttpResponse object is adequate, the ideal situation would
be to run assertions against the template context as well. If you
just run assertions against the HttpResponse object you end up having
to process the HTML in some way to work out if the test has passed.

I'm inclined to agree with Malcolm here - imposing the assertion API isn't the right approach. We should let the user's testing framework provide the assert/fail methods. Django's responsibilty should be to provide variables and methods that can be asserted. So, (again, exact names up for debate), a python unittest test should end up looking something like:

def test_stuff(self):
   response = self.testServer.get('/polls/1')

   self.assertEqual(response.status, 200)
   self.assert_('This is poll 1' in response)
 
   self.assertEqual(response.template , 'poll_detail.html')
   self.assertEqual(response.context['poll.1'], 1)  
   self.assertEqual(response.context['poll.title'], 'poll 1')

But a simple hand cranked test file might use:

   if response.status != 200:
      raise 'Test Error'

and so on.

The solution I've been thinking about involves Django's event
dispatch system. 

The are only two other solutions that come to mind for me:

1) The template tag based approach that Michael Radziej demonstrated in his patch. While this is a good solution from Michael's perspective (solution that works without having to modify Django source code), I'm not sure it's the right solution for the 'official' test tools.

2) Adding special cases so that the template renderer/context processing phases check 'if TestRequest', add attach the template and context as extra data to the response as appropriate; however, special cases make my eyeballs itch.

Neither of these are particularly attractive, IMHO. A TestServer that attaches to the (various?) signals during the response process and captures context/template detail looks like the best approach to me. +1.

Russ Magee %-)


--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Django developers" group.
To post to this group, send email to django-developers@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-developers
-~----------~----~----~----~------~----~------~--~---

Reply via email to