Added a blurb about new SimpleTestCase class to release notes.

Also, tweaked the cross-referencing of `django.test` symbols.

git-svn-id: http://code.djangoproject.com/svn/django/trunk@17644 bcc190cf-cafb-0310-a4f2-bffc1f526a37

docs/releases/1.4.txt

@@ -484,17 +484,17 @@ project, read the :ref:`migration guide <time-zones-migration-guide>`.
 HTML comparisons in tests
 ~~~~~~~~~~~~~~~~~~~~~~~~~
 
-The :class:`~django.test.testcase.TestCase` base class now has some helpers to
+The base classes in :mod:`django.test` now have some helpers to
 compare HTML without tripping over irrelevant differences in whitespace,
 argument quoting/ordering and closing of self-closing tags. You can either
 compare HTML directly with the new
-:meth:`~django.test.testcase.TestCase.assertHTMLEqual` and
+:meth:`~django.test.SimpleTestCase.assertHTMLEqual` and
-:meth:`~django.test.testcase.TestCase.assertHTMLNotEqual` assertions, or use
+:meth:`~django.test.SimpleTestCase.assertHTMLNotEqual` assertions, or use
 the ``html=True`` flag with
-:meth:`~django.test.testcase.TestCase.assertContains` and
+:meth:`~django.test.TestCase.assertContains` and
-:meth:`~django.test.testcase.TestCase.assertNotContains` to test whether the
+:meth:`~django.test.TestCase.assertNotContains` to test whether the
-client's response contains a given HTML fragment. See the :ref:`assertion
+client's response contains a given HTML fragment. See the :ref:`assertions
-documentation<assertions>` for more.
+documentation <assertions>` for more.
 
 Two new date format strings
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~
@@ -614,6 +614,12 @@ Django 1.4 also includes several smaller improvements worth noting:
   :attr:`Sitemap.protocol <django.contrib.sitemaps.Sitemap.protocol>` class
   attribute.
 
+* A new :class:`django.test.SimpleTestCase` subclass of
+  :class:`unittest.TestCase`
+  that is comparatively lighter than :class:`django.test.TestCase` and
+  company. It can be useful in testing scenarios where e.g. no database
+  interaction is needed. See :ref:`testcase_hierarchy_diagram`.
+
 Backwards incompatible changes in 1.4
 =====================================
 
@@ -1016,8 +1022,8 @@ wild, because they would confuse browsers too.
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 It's now possible to check whether a template was used within a block of
-code with :meth:`~django.test.testcase.TestCase.assertTemplateUsed` and
+code with :meth:`~django.test.test.TestCase.assertTemplateUsed` and
-:meth:`~django.test.testcase.TestCase.assertTemplateNotUsed`. And they
+:meth:`~django.test.test.TestCase.assertTemplateNotUsed`. And they
 can be used as a context manager::
 
     with self.assertTemplateUsed('index.html'):

docs/topics/testing.txt

@@ -1089,8 +1089,12 @@ TestCase
 Normal Python unit test classes extend a base class of
 :class:`unittest.TestCase`. Django provides a few extensions of this base class:
 
-.. image:: _images/django_unittest_classes_hierarchy.png
+.. _testcase_hierarchy_diagram:
-   :alt: Django hierarchy of unit testing helper classes (TestCase subclasses)
+
+.. figure:: _images/django_unittest_classes_hierarchy.png
+   :alt: Hierarchy of Django unit testing classes (TestCase subclasses)
+
+   Hierarchy of Django unit testing classes
 
 .. class:: TestCase()
 
@@ -1166,19 +1170,20 @@ A very thin subclass of :class:`unittest.TestCase`, it extends it with some
 basic functionality like:
 
 * Saving and restoring the Python warning machinery state.
-* Checking that a callable :meth:`raises a certain exeception <TestCase.assertRaisesMessage>`.
+* Checking that a callable :meth:`raises a certain exception <SimpleTestCase.assertRaisesMessage>`.
-* :meth:`Testing form field rendering <assertFieldOutput>`.
+* :meth:`Testing form field rendering <SimpleTestCase.assertFieldOutput>`.
+* Testing server :ref:`HTML responses for the presence/lack of a given fragment <assertions>`.
+* The ability to run tests with :ref:`modified settings <overriding-settings>`
 
 If you need any of the other more complex and heavyweight Django-specific
 features like:
 
-* The ability to run tests with :ref:`modified settings <overriding-settings>`
 * Using the :attr:`~TestCase.client` :class:`~django.test.client.Client`.
 * Testing or using the ORM.
 * Database :attr:`~TestCase.fixtures`.
 * Custom test-time :attr:`URL maps <TestCase.urls>`.
 * Test :ref:`skipping based on database backend features <skipping-tests>`.
-* Our specialized :ref:`assert* <assertions>` metods.
+* The remaining specialized :ref:`assert* <assertions>` methods.
 
 then you should use :class:`~django.test.TransactionTestCase` or
 :class:`~django.test.TestCase` instead.
@@ -1515,7 +1520,7 @@ message generated by the assertion. This allows you to provide additional
 details that may help you to identify the location and cause of an failure in
 your test suite.
 
-.. method:: TestCase.assertRaisesMessage(expected_exception, expected_message, callable_obj=None, *args, **kwargs)
+.. method:: SimpleTestCase.assertRaisesMessage(expected_exception, expected_message, callable_obj=None, *args, **kwargs)
 
     .. versionadded:: 1.4
 
@@ -1525,7 +1530,7 @@ your test suite.
     failure. Similar to unittest's :meth:`~unittest.TestCase.assertRaisesRegexp`
     with the difference that ``expected_message`` isn't a regular expression.
 
-.. method:: assertFieldOutput(self, fieldclass, valid, invalid, field_args=None, field_kwargs=None, empty_value=u'')
+.. method:: SimpleTestCase.assertFieldOutput(self, fieldclass, valid, invalid, field_args=None, field_kwargs=None, empty_value=u'')
 
     .. versionadded:: 1.4
 
@@ -1559,7 +1564,7 @@ your test suite.
     the response content will be based on HTML semantics instead of
     character-by-character equality. Whitespace is ignored in most cases,
     attribute ordering is not significant. See
-    :func:`~TestCase.assertHTMLEqual` for more details.
+    :meth:`~SimpleTestCase.assertHTMLEqual` for more details.
 
 .. method:: TestCase.assertNotContains(response, text, status_code=200, msg_prefix='', html=False)
 
@@ -1572,7 +1577,7 @@ your test suite.
     the response content will be based on HTML semantics instead of
     character-by-character equality. Whitespace is ignored in most cases,
     attribute ordering is not significant. See
-    :func:`~TestCase.assertHTMLEqual` for more details.
+    :meth:`~SimpleTestCase.assertHTMLEqual` for more details.
 
 .. method:: TestCase.assertFormError(response, form, field, errors, msg_prefix='')
 
@@ -1617,7 +1622,7 @@ your test suite.
     .. versionadded:: 1.4
 
     You can use this as a context manager in the same way as
-    :func:`~TestCase.assertTemplateUsed`.
+    :meth:`~TestCase.assertTemplateUsed`.
 
 .. method:: TestCase.assertRedirects(response, expected_url, status_code=302, target_status_code=200, msg_prefix='')
 
@@ -1676,7 +1681,7 @@ your test suite.
             Person.objects.create(name="Aaron")
             Person.objects.create(name="Daniel")
 
-.. method:: TestCase.assertHTMLEqual(html1, html2, msg=None)
+.. method:: SimpleTestCase.assertHTMLEqual(html1, html2, msg=None)
 
     .. versionadded:: 1.4
 
@@ -1707,13 +1712,13 @@ your test suite.
     ``html1`` and ``html2`` must be valid HTML. An ``AssertionError`` will be
     raised if one of them cannot be parsed.
 
-.. method:: TestCase.assertHTMLNotEqual(html1, html2, msg=None)
+.. method:: SimpleTestCase.assertHTMLNotEqual(html1, html2, msg=None)
 
     .. versionadded:: 1.4
 
     Asserts that the strings ``html1`` and ``html2`` are *not* equal. The
     comparison is based on HTML semantics. See
-    :func:`~TestCase.assertHTMLEqual` for details.
+    :meth:`~SimpleTestCase.assertHTMLEqual` for details.
 
     ``html1`` and ``html2`` must be valid HTML. An ``AssertionError`` will be
     raised if one of them cannot be parsed.