diff --git a/docs/releases/1.4.txt b/docs/releases/1.4.txt index 8d89555b1fc..cf5815b0230 100644 --- a/docs/releases/1.4.txt +++ b/docs/releases/1.4.txt @@ -484,17 +484,17 @@ project, read the :ref:`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.testcase.TestCase.assertHTMLNotEqual` assertions, or use +:meth:`~django.test.SimpleTestCase.assertHTMLEqual` and +:meth:`~django.test.SimpleTestCase.assertHTMLNotEqual` assertions, or use the ``html=True`` flag with -:meth:`~django.test.testcase.TestCase.assertContains` and -:meth:`~django.test.testcase.TestCase.assertNotContains` to test whether the -client's response contains a given HTML fragment. See the :ref:`assertion -documentation` for more. +:meth:`~django.test.TestCase.assertContains` and +:meth:`~django.test.TestCase.assertNotContains` to test whether the +client's response contains a given HTML fragment. See the :ref:`assertions +documentation ` for more. Two new date format strings ~~~~~~~~~~~~~~~~~~~~~~~~~~~ @@ -614,6 +614,12 @@ Django 1.4 also includes several smaller improvements worth noting: :attr:`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 -:meth:`~django.test.testcase.TestCase.assertTemplateNotUsed`. And they +code with :meth:`~django.test.test.TestCase.assertTemplateUsed` and +:meth:`~django.test.test.TestCase.assertTemplateNotUsed`. And they can be used as a context manager:: with self.assertTemplateUsed('index.html'): diff --git a/docs/topics/testing.txt b/docs/topics/testing.txt index 5c9c978a99d..61fa56a84e3 100644 --- a/docs/topics/testing.txt +++ b/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 - :alt: Django hierarchy of unit testing helper classes (TestCase subclasses) +.. _testcase_hierarchy_diagram: + +.. 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 `. -* :meth:`Testing form field rendering `. +* Checking that a callable :meth:`raises a certain exception `. +* :meth:`Testing form field rendering `. +* Testing server :ref:`HTML responses for the presence/lack of a given fragment `. +* The ability to run tests with :ref:`modified 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 ` * 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 `. * Test :ref:`skipping based on database backend features `. -* Our specialized :ref:`assert* ` metods. +* The remaining specialized :ref:`assert* ` 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.