| author: | Ian Bicking <ianb@colorstudy.com> |
|---|
Contents
WebTest is an extraction of paste.fixture.TestApp, rewriting portions to use WebOb. It is under active development as part of the Paste cloud of packages.
Feedback and discussion should take place on the Paste list, and bugs should go into the Paste Trac instance.
This library is licensed under an MIT-style license.
WebTest is in an svn repository at http://svn.pythonpaste.org/Paste/WebTest/trunk. You can check it out with:
$ svn co http://svn.pythonpaste.org/Paste/WebTest/trunk WebTest
WebTest helps you test your WSGI-based web applications. This can be any application that has a WSGI interface, including an application written in a framework that supports WSGI (which includes most actively developed Python web frameworks – almost anything that even nominally supports WSGI should be testable).
With this you can test your web applications without starting an HTTP server, and without poking into the web framework shortcutting pieces of your application that need to be tested. The tests WebTest runs are entirely equivalent to how a WSGI HTTP server would call an application. By testing the full stack of your application, the WebTest testing model is sometimes called a functional test, integration test, or acceptance test (though the latter two are not particularly good descriptions). This is in contrast to a unit test which tests a particular piece of functionality in your application. While complex programming tasks are often is suited to unit tests, template logic and simple web programming is often best done with functional tests; and regardless of the presence of unit tests, no testing strategy is complete without high-level tests to ensure the entire programming system works together.
WebTest helps you create tests by providing a convenient interface to run WSGI applications and verify the output.
The most important object in WebTest is webtest.TestApp, the wrapper for WSGI applications. To use it, you simply instantiate it with your WSGI application. (Note: if your WSGI application requires any configuration, you must set that up manually in your tests.)
>>> from webtest import TestApp
>>> from webob import Request, Response
>>> from paste.urlmap import URLMap
>>> map_app = URLMap()
>>> form_html = map_app['/form.html'] = Response(content_type='text/html')
>>> form_html.body = '''<html><body>
... <form action="/form-submit" method="POST">
... <input type="text" name="name">
... <input type="submit" name="submit" value="Submit!">
... </form></body></html>'''
>>> app = TestApp(map_app)
>>> res = app.get('/form.html')
>>> res.status
'200 OK'
>>> res.form
<webtest.Form object at ...>
To make a request, use:
app.get('/path', [headers], [extra_environ], ...)
This does a request for /path, with any extra headers or WSGI environment keys that you indicate. This returns a response object, based on webob.Response. It has some additional methods to make it easier to test.
If you want to do a POST request, use:
app.post('/path', {'vars': 'values'}, [headers], [extra_environ],
[upload_files], ...)
Specifically the second argument is the body of the request. You can pass in a dictionary (or dictionary-like object), or a string body (dictionary objects are turned into HTML form submissions).
You can also pass in the keyword argument upload_files, which is a list of [(fieldname, filename, fild_content)]. File uploads use a different form submission data type to pass the structured data.
For other verbs you can use:
app.put(path, params, ...) app.delete(path, ...)
These do PUT and DELETE requests.
The best way to simulate authentication is if your application looks in environ['REMOTE_USER'] to see if someone is authenticated. Then you can simply set that value, like:
app.get('/secret', extra_environ=dict(REMOTE_USER='bob'))
If you want all your requests to have this key, do:
app = TestApp(my_app, extra_environ=dict(REMOTE_USER='bob'))
A key concept behind WebTest is that there’s lots of things you shouldn’t have to check everytime you do a request. It is assumed that the response will either be a 2xx or 3xx response; if it isn’t an exception will be raised (you can override this for a request, of course). The WSGI application is tested for WSGI compliance with a slightly modified version of wsgiref.validate (modified to support arguments to InputWrapper.readline) automatically. Also it checks that nothing is printed to the environ['wsgi.errors'] error stream, which typically indicates a problem (one that would be non-fatal in a production situation, but if you are testing is something you should avoid).
To indicate another status is expected, use the keyword argument status=404 to (for example) check that it is a 404 status, or status="*" to allow any status.
If you expect errors to be printed, use expect_errors=True.
The response object is based on webob.Response with some additions to help with testing.
The inherited attributes that are most interesting:
The added methods:
You can fill out and submit forms from your tests. First you get the form:
>>> res = app.get('/form.html')
>>> form = res.form
Then you fill it in fields:
>>> form.action
'/form-submit'
>>> form.method
'POST'
>>> # dict of fields
>>> fields = form.fields.items(); fields.sort(); fields
[('name', [<webtest.Text object at ...>]), ('submit', [<webtest.Submit object at ...>])]
>>> form['name'] = 'Bob'
>>> # When names don't point to a single field:
>>> form.set('name', 'Bob', index=0)
Then you can submit. First we’ll put up a simple test app to catch the response:
>>> from webtest.debugapp import debug_app
>>> map_app['/form-submit'] = debug_app
Then submit:
>>> # Submit with no particular submit button pressed:
>>> res = form.submit()
>>> # Or submit a button:
>>> res = form.submit('submit')
>>> print res
Response: 200 OK
Content-Type: text/plain
...
-- Body ----------
submit=Submit%21&name=Bob
Select fields can only be set to valid values (i.e., values in an <option>) but you can also use form['select-field'].force_value('value') to enter values not present in an option.
There are several ways to get parsed versions of the response. These are the attributes:
In each case the content-type must be correct or an AttributeError is raised. If you do not have the necessary library installed (none of them are required by WebTest), you will get an ImportError.
Examples:
>>> from webtest import TestResponse
>>> res = TestResponse(content_type='text/html', body='''
... <html><body><div id="content">hey!</div></body>''')
>>> res.html
<BLANKLINE>
<html><body><div id="content">hey!</div></body></html>
>>> res.html.__class__
<class BeautifulSoup.BeautifulSoup at ...>
>>> res.html.body.div.string
u'hey!'
>>> res.lxml
<Element html at ...>
>>> res.lxml.xpath('//body/div')[0].text
'hey!'
>>> res = TestResponse(content_type='application/json',
... body='{"a":1,"b":2}')
>>> res.json
{'a': 1, 'b': 2}
>>> res = TestResponse(content_type='application/xml',
... body='<xml><message>hey!</message></xml>')
>>> res.xml
<Element xml at ...>
>>> res.xml[0].tag
'message'
>>> res.xml[0].text
'hey!'
>>> res.lxml
<Element xml at ...>
>>> res.lxml[0].tag
'message'
>>> res.lxml[0].text
'hey!'
Frameworks can detect that they are in a testing environment by the presence (and truth) of the WSGI environmental variable "paste.testing" (the key name is inherited from paste.fixture).
More generally, frameworks can detect that something (possibly a test fixture) is ready to catch unexpected errors by the presence and truth of "paste.throw_errors" (this is sometimes set outside of testing fixtures too, when an error-handling middleware is in place).
Frameworks that want to expose the inner structure of the request may use "paste.testing_variables". This will be a dictionary – any values put into that dictionary will become attributes of the response object. So if you do env["paste.testing_variables"]['template'] = template_name in your framework, then response.template will be template_name.