Skip to content
This repository

HTTPS clone URL

Subversion checkout URL

You can clone with HTTPS or Subversion.

Download ZIP
Browse code

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
  • Loading branch information...
commit 149e54103415921359e549d5e7fe9f4fbd1ecb75 1 parent dd44170
Ramiro Morales authored March 03, 2012
24  docs/releases/1.4.txt
@@ -484,17 +484,17 @@ project, read the :ref:`migration guide <time-zones-migration-guide>`.
484 484
 HTML comparisons in tests
485 485
 ~~~~~~~~~~~~~~~~~~~~~~~~~
486 486
 
487  
-The :class:`~django.test.testcase.TestCase` base class now has some helpers to
  487
+The base classes in :mod:`django.test` now have some helpers to
488 488
 compare HTML without tripping over irrelevant differences in whitespace,
489 489
 argument quoting/ordering and closing of self-closing tags. You can either
490 490
 compare HTML directly with the new
491  
-:meth:`~django.test.testcase.TestCase.assertHTMLEqual` and
492  
-:meth:`~django.test.testcase.TestCase.assertHTMLNotEqual` assertions, or use
  491
+:meth:`~django.test.SimpleTestCase.assertHTMLEqual` and
  492
+:meth:`~django.test.SimpleTestCase.assertHTMLNotEqual` assertions, or use
493 493
 the ``html=True`` flag with
494  
-:meth:`~django.test.testcase.TestCase.assertContains` and
495  
-:meth:`~django.test.testcase.TestCase.assertNotContains` to test whether the
496  
-client's response contains a given HTML fragment. See the :ref:`assertion
497  
-documentation<assertions>` for more.
  494
+:meth:`~django.test.TestCase.assertContains` and
  495
+:meth:`~django.test.TestCase.assertNotContains` to test whether the
  496
+client's response contains a given HTML fragment. See the :ref:`assertions
  497
+documentation <assertions>` for more.
498 498
 
499 499
 Two new date format strings
500 500
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~
@@ -614,6 +614,12 @@ Django 1.4 also includes several smaller improvements worth noting:
614 614
   :attr:`Sitemap.protocol <django.contrib.sitemaps.Sitemap.protocol>` class
615 615
   attribute.
616 616
 
  617
+* A new :class:`django.test.SimpleTestCase` subclass of
  618
+  :class:`unittest.TestCase`
  619
+  that is comparatively lighter than :class:`django.test.TestCase` and
  620
+  company. It can be useful in testing scenarios where e.g. no database
  621
+  interaction is needed. See :ref:`testcase_hierarchy_diagram`.
  622
+
617 623
 Backwards incompatible changes in 1.4
618 624
 =====================================
619 625
 
@@ -1016,8 +1022,8 @@ wild, because they would confuse browsers too.
1016 1022
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1017 1023
 
1018 1024
 It's now possible to check whether a template was used within a block of
1019  
-code with :meth:`~django.test.testcase.TestCase.assertTemplateUsed` and
1020  
-:meth:`~django.test.testcase.TestCase.assertTemplateNotUsed`. And they
  1025
+code with :meth:`~django.test.test.TestCase.assertTemplateUsed` and
  1026
+:meth:`~django.test.test.TestCase.assertTemplateNotUsed`. And they
1021 1027
 can be used as a context manager::
1022 1028
 
1023 1029
     with self.assertTemplateUsed('index.html'):
33  docs/topics/testing.txt
@@ -1089,8 +1089,12 @@ TestCase
1089 1089
 Normal Python unit test classes extend a base class of
1090 1090
 :class:`unittest.TestCase`. Django provides a few extensions of this base class:
1091 1091
 
1092  
-.. image:: _images/django_unittest_classes_hierarchy.png
1093  
-   :alt: Django hierarchy of unit testing helper classes (TestCase subclasses)
  1092
+.. _testcase_hierarchy_diagram:
  1093
+
  1094
+.. figure:: _images/django_unittest_classes_hierarchy.png
  1095
+   :alt: Hierarchy of Django unit testing classes (TestCase subclasses)
  1096
+
  1097
+   Hierarchy of Django unit testing classes
1094 1098
 
1095 1099
 .. class:: TestCase()
1096 1100
 
@@ -1166,19 +1170,20 @@ A very thin subclass of :class:`unittest.TestCase`, it extends it with some
1166 1170
 basic functionality like:
1167 1171
 
1168 1172
 * Saving and restoring the Python warning machinery state.
1169  
-* Checking that a callable :meth:`raises a certain exeception <TestCase.assertRaisesMessage>`.
1170  
-* :meth:`Testing form field rendering <assertFieldOutput>`.
  1173
+* Checking that a callable :meth:`raises a certain exception <SimpleTestCase.assertRaisesMessage>`.
  1174
+* :meth:`Testing form field rendering <SimpleTestCase.assertFieldOutput>`.
  1175
+* Testing server :ref:`HTML responses for the presence/lack of a given fragment <assertions>`.
  1176
+* The ability to run tests with :ref:`modified settings <overriding-settings>`
1171 1177
 
1172 1178
 If you need any of the other more complex and heavyweight Django-specific
1173 1179
 features like:
1174 1180
 
1175  
-* The ability to run tests with :ref:`modified settings <overriding-settings>`
1176 1181
 * Using the :attr:`~TestCase.client` :class:`~django.test.client.Client`.
1177 1182
 * Testing or using the ORM.
1178 1183
 * Database :attr:`~TestCase.fixtures`.
1179 1184
 * Custom test-time :attr:`URL maps <TestCase.urls>`.
1180 1185
 * Test :ref:`skipping based on database backend features <skipping-tests>`.
1181  
-* Our specialized :ref:`assert* <assertions>` metods.
  1186
+* The remaining specialized :ref:`assert* <assertions>` methods.
1182 1187
 
1183 1188
 then you should use :class:`~django.test.TransactionTestCase` or
1184 1189
 :class:`~django.test.TestCase` instead.
@@ -1515,7 +1520,7 @@ message generated by the assertion. This allows you to provide additional
1515 1520
 details that may help you to identify the location and cause of an failure in
1516 1521
 your test suite.
1517 1522
 
1518  
-.. method:: TestCase.assertRaisesMessage(expected_exception, expected_message, callable_obj=None, *args, **kwargs)
  1523
+.. method:: SimpleTestCase.assertRaisesMessage(expected_exception, expected_message, callable_obj=None, *args, **kwargs)
1519 1524
 
1520 1525
     .. versionadded:: 1.4
1521 1526
 
@@ -1525,7 +1530,7 @@ your test suite.
1525 1530
     failure. Similar to unittest's :meth:`~unittest.TestCase.assertRaisesRegexp`
1526 1531
     with the difference that ``expected_message`` isn't a regular expression.
1527 1532
 
1528  
-.. method:: assertFieldOutput(self, fieldclass, valid, invalid, field_args=None, field_kwargs=None, empty_value=u'')
  1533
+.. method:: SimpleTestCase.assertFieldOutput(self, fieldclass, valid, invalid, field_args=None, field_kwargs=None, empty_value=u'')
1529 1534
 
1530 1535
     .. versionadded:: 1.4
1531 1536
 
@@ -1559,7 +1564,7 @@ your test suite.
1559 1564
     the response content will be based on HTML semantics instead of
1560 1565
     character-by-character equality. Whitespace is ignored in most cases,
1561 1566
     attribute ordering is not significant. See
1562  
-    :func:`~TestCase.assertHTMLEqual` for more details.
  1567
+    :meth:`~SimpleTestCase.assertHTMLEqual` for more details.
1563 1568
 
1564 1569
 .. method:: TestCase.assertNotContains(response, text, status_code=200, msg_prefix='', html=False)
1565 1570
 
@@ -1572,7 +1577,7 @@ your test suite.
1572 1577
     the response content will be based on HTML semantics instead of
1573 1578
     character-by-character equality. Whitespace is ignored in most cases,
1574 1579
     attribute ordering is not significant. See
1575  
-    :func:`~TestCase.assertHTMLEqual` for more details.
  1580
+    :meth:`~SimpleTestCase.assertHTMLEqual` for more details.
1576 1581
 
1577 1582
 .. method:: TestCase.assertFormError(response, form, field, errors, msg_prefix='')
1578 1583
 
@@ -1617,7 +1622,7 @@ your test suite.
1617 1622
     .. versionadded:: 1.4
1618 1623
 
1619 1624
     You can use this as a context manager in the same way as
1620  
-    :func:`~TestCase.assertTemplateUsed`.
  1625
+    :meth:`~TestCase.assertTemplateUsed`.
1621 1626
 
1622 1627
 .. method:: TestCase.assertRedirects(response, expected_url, status_code=302, target_status_code=200, msg_prefix='')
1623 1628
 
@@ -1676,7 +1681,7 @@ your test suite.
1676 1681
             Person.objects.create(name="Aaron")
1677 1682
             Person.objects.create(name="Daniel")
1678 1683
 
1679  
-.. method:: TestCase.assertHTMLEqual(html1, html2, msg=None)
  1684
+.. method:: SimpleTestCase.assertHTMLEqual(html1, html2, msg=None)
1680 1685
 
1681 1686
     .. versionadded:: 1.4
1682 1687
 
@@ -1707,13 +1712,13 @@ your test suite.
1707 1712
     ``html1`` and ``html2`` must be valid HTML. An ``AssertionError`` will be
1708 1713
     raised if one of them cannot be parsed.
1709 1714
 
1710  
-.. method:: TestCase.assertHTMLNotEqual(html1, html2, msg=None)
  1715
+.. method:: SimpleTestCase.assertHTMLNotEqual(html1, html2, msg=None)
1711 1716
 
1712 1717
     .. versionadded:: 1.4
1713 1718
 
1714 1719
     Asserts that the strings ``html1`` and ``html2`` are *not* equal. The
1715 1720
     comparison is based on HTML semantics. See
1716  
-    :func:`~TestCase.assertHTMLEqual` for details.
  1721
+    :meth:`~SimpleTestCase.assertHTMLEqual` for details.
1717 1722
 
1718 1723
     ``html1`` and ``html2`` must be valid HTML. An ``AssertionError`` will be
1719 1724
     raised if one of them cannot be parsed.

0 notes on commit 149e541

Please sign in to comment.
Something went wrong with that request. Please try again.