Fixed #11253 -- Normalized the way the docs refer to TestCase.assert* methods....

its own test database. That is, any test that accesses a database -- by

creating and saving model instances, for example -- will not affect your

production database. However, the database is not refreshed between doctests,

so if your doctest requires a certain state you should consider flushin the 

so if your doctest requires a certain state you should consider flushing the

database or loading a fixture. (See the section on fixtures, below, for more

on this.) Note that to use this feature, the database user Django is connecting

as must have ``CREATE DATABASE`` rights.

    Asserts that a ``Response`` instance produced the given ``status_code`` and

    that ``text`` does not appears in the content of the response.

.. method:: assertFormError(response, form, field, errors)

.. method:: TestCase.assertFormError(response, form, field, errors)

    Asserts that a field on a form raises the provided list of errors when

    rendered on the form.

    ``errors`` is an error string, or a list of error strings, that are

    expected as a result of form validation.

.. method:: assertTemplateUsed(response, template_name)

.. method:: TestCase.assertTemplateUsed(response, template_name)

    Asserts that the template with the given name was used in rendering the

    response.

    The name is a string such as ``'admin/index.html'``.

.. method:: assertTemplateNotUsed(response, template_name)

.. method:: TestCase.assertTemplateNotUsed(response, template_name)

    Asserts that the template with the given name was *not* used in rendering

    the response.

.. method:: assertRedirects(response, expected_url, status_code=302, target_status_code=200)

.. method:: TestCase.assertRedirects(response, expected_url, status_code=302, target_status_code=200)

    Asserts that the response return a ``status_code`` redirect status, it

    redirected to ``expected_url`` (including any GET data), and the final