Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with
or
.
Download ZIP
Browse files

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 ramiro authored
Showing with 34 additions and 23 deletions.
  1. +15 −9 docs/releases/1.4.txt
  2. +19 −14 docs/topics/testing.txt
View
24 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.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<assertions>` 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 <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
-: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'):
View
33 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 <TestCase.assertRaisesMessage>`.
-* :meth:`Testing form field rendering <assertFieldOutput>`.
+* Checking that a callable :meth:`raises a certain exception <SimpleTestCase.assertRaisesMessage>`.
+* :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.
Please sign in to comment.
Something went wrong with that request. Please try again.