#2333: Add unit test framework for end-user Django applications
-------------------------------+--------------------------------------------
Reporter: russellm | Owner: russellm
Type: enhancement | Status: new
Priority: normal | Milestone:
Component: Unit test system | Version: SVN
Severity: normal | Resolution:
Keywords: unit test doctest |
-------------------------------+--------------------------------------------
Comment (by russellm):
Here's the next piece of the testing puzzle - a method for testing
contexts and templates produced by views.
It acts a little bit like an automatable web browser. The interface allows
users to make GET and POST requests; what is returned is a 'test decorated
Response' - a normal HttpResponse object, but with extra attributes
(specifically, 'context' and 'template') that describe the contexts and
templates that were rendered in the process of serving the request.
If a single template was rendered, response.template and response.context
will point to the template and context dictionary respectively. If
multiple templates were rendered, response.template and response.context
will be lists, set such that response.context[n] was used on
response.template[n]. If no templates were rendered, response.template and
response.context will be None.
Cookies are also handled in a limited fashion, and are preserved for the
lifespan of the Browser instance. A simple helper interface exists to
assist with submitting to login pages so that you can test @login_required
views.
This is all acheived by directly hooking into the WSGI interface, so no
server instance is required for the Browser to be used. Template and
context details are obtained by listening to a new signal that is emitted
whenever the render() method is invoked on a template.
As noted in the patch - this is not intended to reproduce or replace tools
such as Twill or Selenium. While these tools are good tests of client
behaviour, they cannot check the contents of Context or Template rendering
details (except at the level of 'is the rendered output correct').
As noted with the previous patches, the approach here is not to enforce a
particular testing framework, but to provide the tools that allow anyone
to test any aspect of their Django application.
Here's a sample test session:
{{{
from django.test.browser import Browser
# Create a browser
b = Browser()
# Login to the server as 'fred'
assert b.login('/login/',fred,password), "Couldn't log in!"
# GET the page with Widget 3
response = b.get('/widgets/3/')
# Check some response details
assert response.status_code == 200
assert response.context['widget_name'] == 'foo'
assert response.template.name == 'mytemplate.html'
assert '<b>Widget details</b>' in response.content
# POST a new widget
img = open('widget.jpg','r')
post_data = {
'name': 'bar',
'size': 3
'image': img
}
response = b.post('/widgets/new', post_data)
img.close()
# Check that submit page redirected us somewhere
assert response.status_code == 302
}}}
Comments?
--
Ticket URL: <http://code.djangoproject.com/ticket/2333>
Django <http://code.djangoproject.org/>
The web framework for perfectionists with deadlines.
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Django updates" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-updates
-~----------~----~----~----~------~----~------~--~---
