# Test Utilities

Quite often you want to unittest your application or just check the output from an interactive python session. In theory that is pretty simple because you can fake a WSGI environment and call the application with a dummy start_response and iterate over the application iterator but there are argumentably better ways to interact with an application.

## Diving In

Werkzeug provides a Client object which you can pass a WSGI application (and optionally a response wrapper) which you can use to send virtual requests to the application.

A response wrapper is a callable that takes three arguments: the application iterator, the status and finally a list of headers. The default response wrapper returns a tuple. Because response objects have the same signature, you can use them as response wrapper, ideally by subclassing them and hooking in test functionality.

    >>> from werkzeug.test import Client
    >>> from werkzeug.testapp import test_app
    >>> from werkzeug.wrappers import BaseResponse
    >>> c = Client(test_app, BaseResponse)
    >>> resp = c.get('/')
    >>> resp.status_code
    200
    >>> resp.headers
    Headers([('Content-Type', 'text/html; charset=utf-8'), ('Content-Length', '8339')])
    >>> resp.data.splitlines()[0]
    '<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"'

Or without a wrapper defined:

    >>> c = Client(test_app)
    >>> app_iter, status, headers = c.get('/')
    >>> status
    '200 OK'
    >>> headers
    [('Content-Type', 'text/html; charset=utf-8'), ('Content-Length', '8339')]
    >>> ''.join(app_iter).splitlines()[0]
    '<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"'

## Environment Building

New in version 0.5.

The easiest way to interactively test applications is using the `EnvironBuilder`. It can create both standard WSGI environments and request objects.

The following example creates a WSGI environment with one uploaded file and a form field:

    >>> from werkzeug.test import EnvironBuilder
    >>> from StringIO import StringIO
    >>> builder = EnvironBuilder(method='POST', data={'foo': 'this is some text',
    ...      'file': (StringIO('my file contents'), 'test.txt')})
    >>> env = builder.get_environ()

The resulting environment is a regular WSGI environment that can be used for further processing:

    >>> from werkzeug.wrappers import Request
    >>> req = Request(env)
    >>> req.form['foo']
    u'this is some text'
    >>> req.files['file']
    <FileStorage: u'test.txt' ('text/plain')>
    >>> req.files['file'].read()
    'my file contents'

The `EnvironBuilder` figures out the content type automatically if you pass a dict to the constructor as data. If you provide a string or an input stream you have to do that yourself.

By default it will try to use `application/x-www-form-urlencoded` and only use `multipart/form-data` if files are uploaded:

    >>> builder = EnvironBuilder(method='POST', data={'foo': 'bar'})
    >>> builder.content_type
    'application/x-www-form-urlencoded'
    >>> builder.files['foo'] = StringIO('contents')
    >>> builder.content_type
    'multipart/form-data'

If a string is provided as data (or an input stream) you have to specify the content type yourself:

    >>> builder = EnvironBuilder(method='POST', data='{"json": "this is"}')
    >>> builder.content_type
    >>> builder.content_type = 'application/json'

## Testing API

class `werkzeug.test.``EnvironBuilder`(path='/', base_url=None, query_string=None, method='GET', input_stream=None, content_type=None, content_length=None, errors_stream=None, multithread=False, multiprocess=False, run_once=False, headers=None, data=None, environ_base=None, environ_overrides=None, charset='utf-8')

  This class can be used to conveniently create a WSGI environment for testing purposes. It can be used to quickly create WSGI environments or request objects from arbitrary data.

  The signature of this class is also used in some other places as of Werkzeug 0.5 (`create_environ()`, `BaseResponse.from_values()`, `Client.open()`). Because of this most of the functionality is available through the constructor alone.

  Files and regular form data can be manipulated independently of each other with the `form` and `files` attributes, but are passed with the same argument to the constructor: data.

  data can be any of these values:

  - a str or bytes object: The object is converted into an `input_stream`, the `content_length` is set and you have to provide a `content_type`.
  - a dict or `MultiDict`: The keys have to be strings. The values have to be either any of the following objects, or a list of any of the following objects:
    - a `file`-like object: These are converted into `FileStorage` objects automatically.
    - a tuple: The `add_file()` method is called with the key and the unpacked tuple items as positional arguments.
    - a str: The string is set as form data for the associated key.
  - a file-like object: The object content is loaded in memory and then handled like a regular str or a bytes.

  New in version 0.6: path and base_url can now be unicode strings that are encoded using the `iri_to_uri()` function.

  Parameters: | path – the path of the request. In the WSGI environment this will end up as PATH_INFO. If the query_string is not defined and there is a question mark in the path everything after it is used as query string. base_url – the base URL is a URL that is used to extract the WSGI URL scheme, host (server name + server port) and the script root (SCRIPT_NAME). query_string – an optional string or dict with URL parameters. method – the HTTP method to use, defaults to GET. input_stream – an optional input stream. Do not specify this and data. As soon as an input stream is set you can’t modify `args` and `files` unless you set the `input_stream` to None again. content_type – The content type for the request. As of 0.5 you don’t have to provide this when specifying files and form data via data. content_length – The content length for the request. You don’t have to specify this when providing data via data. errors_stream – an optional error stream that is used for wsgi.errors. Defaults to `stderr`. multithread – controls wsgi.multithread. Defaults to False. multiprocess – controls wsgi.multiprocess. Defaults to False. run_once – controls wsgi.run_once. Defaults to False. headers – an optional list or `Headers` object of headers. data – a string or dict of form data or a file-object. See explanation above. environ_base – an optional dict of environment defaults. environ_overrides – an optional dict of environment overrides. charset – the charset used to encode unicode data.

  `path`

    The path of the application. (aka PATH_INFO)

  `charset`

    The charset used to encode unicode data.

  `headers`

    A `Headers` object with the request headers.

  `errors_stream`

    The error stream used for the wsgi.errors stream.

  `multithread`

    The value of wsgi.multithread

  `multiprocess`

    The value of wsgi.multiprocess

  `environ_base`

    The dict used as base for the newly create environ.

  `environ_overrides`

    A dict with values that are used to override the generated environ.

  `input_stream`

    The optional input stream. This and `form` / `files` is mutually exclusive. Also do not provide this stream if the request method is not POST / PUT or something comparable.

  `args`

    The URL arguments as `MultiDict`.

  `base_url`

    The base URL is a URL that is used to extract the WSGI URL scheme, host (server name + server port) and the script root (SCRIPT_NAME).

  `close`()

    Closes all files. If you put real `file` objects into the `files` dict you can call this method to automatically close them all in one go.

  `content_length`

    The content length as integer. Reflected from and to the `headers`. Do not set if you set `files` or `form` for auto detection.

  `content_type`

    The content type for the request. Reflected from and to the `headers`. Do not set if you set `files` or `form` for auto detection.

  `files`

    A `FileMultiDict` of uploaded files. You can use the `add_file()` method to add new files to the dict.

  `form`

    A `MultiDict` of form values.

  `get_environ`()

    Return the built environ.

  `get_request`(cls=None)

    Returns a request with the data. If the request class is not specified `request_class` is used.

    Parameters: | cls – The request wrapper to use.

  `input_stream`

    An optional input stream. If you set this it will clear `form` and `files`.

  `query_string`

    The query string. If you set this to a string `args` will no longer be available.

  `request_class`

    the default request class for `get_request()`

    alias of `BaseRequest`

  `server_name`

    The server name (read-only, use `host` to set)

  `server_port`

    The server port as integer (read-only, use `host` to set)

  `server_protocol` = 'HTTP/1.1'

    the server protocol to use. defaults to HTTP/1.1

  `wsgi_version` = (1, 0)

    the wsgi version to use. defaults to (1, 0)

class `werkzeug.test.``Client`(application, response_wrapper=None, use_cookies=True, allow_subdomain_redirects=False)

  This class allows to send requests to a wrapped application.

  The response wrapper can be a class or factory function that takes three arguments: app_iter, status and headers. The default response wrapper just returns a tuple.

  Example:

      class ClientResponse(BaseResponse):
          ...

      client = Client(MyApplication(), response_wrapper=ClientResponse)

  The use_cookies parameter indicates whether cookies should be stored and sent for subsequent requests. This is True by default, but passing False will disable this behaviour.

  If you want to request some subdomain of your application you may set allow_subdomain_redirects to True as if not no external redirects are allowed.

  New in version 0.5: use_cookies is new in this version. Older versions did not provide builtin cookie support.

  `open`(*args, **kwargs)

    Takes the same arguments as the `EnvironBuilder` class with some additions: You can provide a `EnvironBuilder` or a WSGI environment as only argument instead of the `EnvironBuilder` arguments and two optional keyword arguments (as_tuple, buffered) that change the type of the return value or the way the application is executed.

    Changed in version 0.5: If a dict is provided as file in the dict for the data parameter the content type has to be called content_type now instead of mimetype. This change was made for consistency with `werkzeug.FileWrapper`.

    > The follow_redirects parameter was added to `open()`.

    Additional parameters:

    Parameters: | as_tuple – Returns a tuple in the form `(environ, result)` buffered – Set this to True to buffer the application run. This will automatically close the application for you as well. follow_redirects – Set this to True if the Client should follow HTTP redirects.

  Shortcut methods are available for many HTTP methods:

  `get`(*args, **kw)

    Like open but method is enforced to GET.

  `patch`(*args, **kw)

    Like open but method is enforced to PATCH.

  `post`(*args, **kw)

    Like open but method is enforced to POST.

  `head`(*args, **kw)

    Like open but method is enforced to HEAD.

  `put`(*args, **kw)

    Like open but method is enforced to PUT.

  `delete`(*args, **kw)

    Like open but method is enforced to DELETE.

  `options`(*args, **kw)

    Like open but method is enforced to OPTIONS.

  `trace`(*args, **kw)

    Like open but method is enforced to TRACE.

`werkzeug.test.``create_environ`([options])

  Create a new WSGI environ dict based on the values passed. The first parameter should be the path of the request which defaults to ‘/’. The second one can either be an absolute path (in that case the host is localhost:80) or a full path to the request with scheme, netloc port and the path to the script.

  This accepts the same arguments as the `EnvironBuilder` constructor.

  Changed in version 0.5: This function is now a thin wrapper over `EnvironBuilder` which was added in 0.5. The headers, environ_base, environ_overrides and charset parameters were added.

`werkzeug.test.``run_wsgi_app`(app, environ, buffered=False)

  Return a tuple in the form (app_iter, status, headers) of the application output. This works best if you pass it an application that returns an iterator all the time.

  Sometimes applications may use the write() callable returned by the start_response function. This tries to resolve such edge cases automatically. But if you don’t get the expected output you should set buffered to True which enforces buffering.

  If passed an invalid WSGI application the behavior of this function is undefined. Never pass non-conforming WSGI applications to this function.

  Parameters: | app – the application to execute. buffered – set to True to enforce buffering.
  Returns: | tuple in the form `(app_iter, status, headers)`