Fixed #14503 -- Unified multiple implementations of test cases assert* methods that verify a given exception is raised by a callable throughout the Django test suite.

Replaced them with a new assertRaisesMessage method of a new SimpleTestCase, a lightweight subclass of unittest.TestCase. Both are also available for usage in user tests.

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

2 files changed, 58 insertions, 14 deletions

diff --git a/docs/ref/signals.txt b/docs/ref/signals.txt
index b265d078eb..5f55bbe418 100644
--- a/docs/ref/signals.txt
+++ b/docs/ref/signals.txt
@@ -480,7 +480,7 @@ setting_changed
 .. data:: django.test.signals.setting_changed
    :module:
 
-Sent when some :ref:`settings are overridden <overriding-setting>` with the
+Sent when some :ref:`settings are overridden <overriding-settings>` with the
 :meth:`django.test.TestCase.setting` context manager or the
 :func:`django.test.utils.override_settings` decorator/context manager.
 
diff --git a/docs/topics/testing.txt b/docs/topics/testing.txt
index 8cb00e39a4..c5a18f8680 100644
--- a/docs/topics/testing.txt
+++ b/docs/topics/testing.txt
@@ -715,7 +715,7 @@ arguments at time of construction:
             The headers sent via ``**extra`` should follow CGI_ specification.
             For example, emulating a different "Host" header as sent in the
             HTTP request from the browser to the server should be passed
-            as ``HTTP_HOST``. 
+            as ``HTTP_HOST``.
 
             .. _CGI: http://www.w3.org/CGI/
 
@@ -1101,7 +1101,7 @@ TestCase
 .. currentmodule:: django.test
 
 Normal Python unit test classes extend a base class of ``unittest.TestCase``.
-Django provides an extension of this base class:
+Django provides a few extensions of this base class:
 
 .. class:: TestCase()
 
@@ -1123,6 +1123,8 @@ additions, including:
     * Django-specific assertions for testing for things
       like redirection and form errors.
 
+``TestCase`` inherits from :class:`~django.test.TransactionTestCase`.
+
 .. class:: TransactionTestCase()
 
 Django ``TestCase`` classes make use of database transaction facilities, if
@@ -1153,6 +1155,7 @@ When running on a database that does not support rollback (e.g. MySQL with the
 MyISAM storage engine), ``TestCase`` falls back to initializing the database
 by truncating tables and reloading initial data.
 
+``TransactionTestCase`` inherits from :class:`~django.test.SimpleTestCase`.
 
 .. note::
     The ``TestCase`` use of rollback to un-do the effects of the test code
@@ -1166,6 +1169,31 @@ by truncating tables and reloading initial data.
     A better long-term fix, that allows the test to take advantage of the
     speed benefit of ``TestCase``, is to fix the underlying test problem.
 
+.. class:: SimpleTestCase()
+
+.. versionadded:: 1.4
+
+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>`.
+
+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.
+
+then you should use :class:`~django.test.TransactionTestCase` or
+:class:`~django.test.TestCase` instead.
+
+``SimpleTestCase`` inherits from :class:`django.utils.unittest.TestCase`.
 
 Default test client
 ~~~~~~~~~~~~~~~~~~~
@@ -1370,7 +1398,7 @@ For example::
 This test case will flush *all* the test databases before running
 ``testIndexPageView``.
 
-.. _overriding-setting:
+.. _overriding-settings:
 
 Overriding settings
 ~~~~~~~~~~~~~~~~~~~
@@ -1402,7 +1430,9 @@ this use case Django provides a standard `Python context manager`_
 This example will override the :setting:`LOGIN_URL` setting for the code
 in the ``with`` block and reset its value to the previous state afterwards.
 
-.. function:: utils.override_settings
+.. currentmodule:: django.test.utils
+
+.. function:: override_settings
 
 In case you want to override a setting for just one test method or even the
 whole TestCase class, Django provides the
@@ -1463,9 +1493,13 @@ contents of the test email outbox at the start of each test case.
 
 For more detail on email services during tests, see `Email services`_.
 
+.. _assertions:
+
 Assertions
 ~~~~~~~~~~
 
+.. currentmodule:: django.test
+
 .. versionchanged:: 1.2
     Addded ``msg_prefix`` argument.
 
@@ -1474,11 +1508,19 @@ such as ``assertTrue`` and ``assertEqual``, Django's custom ``TestCase`` class
 provides a number of custom assertion methods that are useful for testing Web
 applications:
 
-The failure messages given by the assertion methods can be customized
-with the ``msg_prefix`` argument. This string will be prefixed to any
-failure 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.
+The failure messages given by most of these assertion methods can be customized
+with the ``msg_prefix`` argument. This string will be prefixed to any failure
+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)
+
+    Asserts that execution of callable ``callable_obj`` raised the
+    ``expected_exception`` exception and that such exception has an
+    ``expected_message`` representation. Any other outcome is reported as a
+    failure. Similar to unittest's ``assertRaisesRegexp`` with the difference
+    that ``expected_message`` isn't a regular expression.
 
 .. method:: TestCase.assertContains(response, text, count=None, status_code=200, msg_prefix='')
 
@@ -1626,9 +1668,13 @@ manually, assign the empty list to ``mail.outbox``::
     # Empty the test outbox
     mail.outbox = []
 
+.. _skipping-tests:
+
 Skipping tests
 --------------
 
+.. currentmodule:: django.test
+
 .. versionadded:: 1.3
 
 The unittest library provides the ``@skipIf`` and ``@skipUnless``
@@ -1651,8 +1697,7 @@ features class. See :class:`~django.db.backends.BaseDatabaseFeatures`
 class for a full list of database features that can be used as a basis
 for skipping tests.
 
-skipIfDBFeature
-~~~~~~~~~~~~~~~
+.. function:: skipIfDBFeature(feature_name_string)
 
 Skip the decorated test if the named database feature is supported.
 
@@ -1665,8 +1710,7 @@ it would under MySQL with MyISAM tables)::
         def test_transaction_behavior(self):
             # ... conditional test code
 
-skipUnlessDBFeature
-~~~~~~~~~~~~~~~~~~~
+.. function:: skipUnlessDBFeature(feature_name_string)
 
 Skip the decorated test if the named database feature is *not*
 supported.