Author: | Ian Bicking <ianb@colorstudy.com> |
---|---|
Revision: | 6575 |
Date: | 2007-05-24 21:07:38 -0500 (Thu, 24 May 2007) |
Paste includes functionality for testing your application in a convenient manner. These facilities are quite young, and feedback is invited. Feedback and discussion should take place on the Paste-users list.
These facilities let you test your Paste and WSGI-based applications easily and without a server.
If you have questions about this document, please contact the paste mailing list or try IRC (#pythonpaste on freenode.net). If there's something that confused you and you want to give feedback, please submit an issue.
This has been written with py.test in mind. The py.test convention is to put tests in modules named test_*.py, and the actual test functions are also named starting with test_.
In your testing module you should do:
from paste.tests.fixture import setup_module
This will add some initialization, will load your configure, will call a reset_state function if you define one, and will insert the variables app and CONFIG in your module.
If you have path problems you can set $PYTHONPATH, or you can add something to a conftest.py module, like:
import sys sys.path.append('path/to/Paste', ...)
Note that paths given in the sys_path configuration item will also be loaded (but Paste itself must be found first).
The app object is a wrapper around your application, with many methods to make testing convenient. Here's an example test script:
def test_myapp(): res = app.get('/view', params={'id': 10}) # We just got /view?id=10 res.mustcontain('Item 10') res = app.post('/view', params={'id': 10, 'name': 'New item name'}) # The app does POST-and-redirect... res = res.follow() assert res.request.url == '/view?id=10' res.mustcontain('New item name') res.mustcontain('Item updated')
The methods of the app object (a paste.tests.fixture.TestApp object):
Gets the URL. URLs are based in the root of your application; no domains are allowed. Parameters can be given as a dictionary, or included directly in the url. Headers can also be added.
This tests that the status is a 200 OK or a redirect header, unless you pass in a status. A status of "*" will never fail; or you can assert a specific status (like 500).
Also, if any errors are written to the error stream this will raise an error.
POSTS to the URL. Like GET, except also allows for uploading files. The uploaded files are a list of (field_name, filename, file_content).
If you don't want to do a urlencoded post body, you can put a content-type header in your header, and pass the body in as a string with params.
The response object:
Request objects:
You can fill out and submit forms from your tests. First you get the form:
res = testapp.get('/entry_form') form = res.forms[0]
Then you fill it in fields:
# when there's one unambiguous name field: form['name'] = 'Bob' # Enter something into the first field named 'age' form.set('age', '45', index=1)
Finally you submit:
# Submit with no particular submit button pressed: form.submit() # Or submit a button: form.submit('submit_button_name')
Frameworks can detect that they are in a testing environment by the presence (and truth) of the WSGI environmental variable "paste.testing".
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.