Remove mentions of TestCase subclassing and simplify.

1 files changed, 34 insertions, 62 deletions

diff --git a/doc/TESTS.txt b/doc/TESTS.txt
index 63de7327d..c2e23ef9d 100644
--- a/doc/TESTS.txt
+++ b/doc/TESTS.txt
@@ -77,72 +77,43 @@ Writing your own tests
 
 Every Python module, extension module, or subpackage in the SciPy
 package directory should have a corresponding ``test_<name>.py`` file.
-The nose framework picks up tests by first looking for any functions
-in the file that have test-related names (see below), or classes that
-inherit from ``unittest.TestCase`` (which is also made available as
-``numpy.testing.TestCase``.  Any methods of these classes, that also
-have test-related names, are considered tests.  A test-related name is
-simply a function or method name containing 'test'.
+Nose examines these files for test methods (named test*) and test
+classes (named Test*).
 
 Suppose you have a SciPy module ``scipy/xxx/yyy.py`` containing a
-function ``zzz()``. To test this you would start by creating a test
-module called ``test_yyy.py``. There are several different ways to
-implement tests using the nose / SciPy system.  There is the standard
-unittest way and the nose test function way.
-
-Standard unit test classes
---------------------------
-
-You can use the traditional unittest system by making your test file
-include a class that tests ``zzz()``. The test class inherits from the
-TestCase class, and has test methods that test various aspects of
-``zzz()``. Within these test methods, ``assert()`` is used to test
-whether some case is true. If the assert fails, the test fails. The
-line ``nose.run(...)`` function actually runs the test suite. A
-minimal example of a ``test_yyy.py`` file that implements tests for a
-Scipy package module ``scipy.xxx.yyy``, is shown below::
+function ``zzz()``.  To test this function you would create a test
+module called ``test_yyy.py``.  If you only need to test one aspect of
+``zzz``, you can simply add a test function::
+
+  def test_zzz():
+      assert zzz() == 'Hello from zzz'
+
+More often, we need to group a number of tests together, so we create
+a test class::
 
   from numpy.testing import *
 
   # import xxx symbols
   from scipy.xxx.yyy import zzz
 
-  class test_zzz(TestCase):
+  class TestZzz:
       def test_simple(self):
-          assert zzz()=='Hello from zzz'
-      #...
-
-  if __name__ == "__main__":
-      run_module_suite()
-
-
-Note that all classes that are inherited from ``TestCase`` class, are
-picked up by the test runner. For more detailed information on
-defining test classes see the official documentation for the `Python
-Unit testing framework
-<http://docs.python.org/lib/module-unittest.html>`__.
-
-Using test functions with nose
-------------------------------
+          assert zzz() == 'Hello from zzz'
 
-This is as simple as making a function or functions with names
-including 'test'::
+      def test_invalid_parameter(self):
+          assert_raises(...)
 
-  from numpy.testing import *
-
-  # import xxx symbols
-  from scipy.xxx.yyy import zzz
+Within these test methods, ``assert()`` is used to test whether a
+certain assumption is valid. If the assert fails, the test fails.
 
-  def test_simple(self):
-      assert zzz()=='Hello from zzz'
+Sometimes it is convenient to run ``test_yyy.py`` by itself, so we add
 
+::
 
   if __name__ == "__main__":
       run_module_suite()
 
-
-You can mix nose test functions and TestCase classes in a single test
-file.
+at the bottom.
 
 Labeling tests with nose
 ------------------------
@@ -154,16 +125,17 @@ can label it with a nose decorator::
 
   # numpy.testing module includes 'import decorators as dec'
   from numpy.testing import *
+
   @dec.slow
   def test_big(self):
       print 'Big, slow test'
 
 Similarly for methods::
 
-  class test_zzz(TestCase):
+  class test_zzz:
       @dec.slow
       def test_simple(self):
-          assert zzz()=='Hello from zzz'
+          assert zzz() == 'Hello from zzz'
 
 Easier setup and teardown functions / methods
 ---------------------------------------------
@@ -221,7 +193,12 @@ with test generators::
 
 Note that 'check_even' is not itself a test (no 'test' in the name),
 but 'test_evens' is a generator that returns a series of tests, using
-'check_even', across a range of inputs.  Nice.
+'check_even', across a range of inputs.
+
+.. warning::
+
+   Parametric tests cannot be implemented on classes derived from
+   UnitTest.
 
 Doctests
 --------
@@ -253,7 +230,8 @@ subdirectory. For our example, if it doesn't all ready exist you will
 need to create a ``tests/`` directory in ``scipy/xxx/``. So the path
 for ``test_yyy.py`` is ``scipy/xxx/tests/test_yyy.py``.
 
-Once the ``scipy/xxx/tests/test_yyy.py`` is written, its possible to run the tests by going to the ``tests/`` directory and typing::
+Once the ``scipy/xxx/tests/test_yyy.py`` is written, its possible to
+run the tests by going to the ``tests/`` directory and typing::
 
   python test_yyy.py
 
@@ -266,7 +244,7 @@ the tests interactively in the interpreter like this::
 ``__init__.py`` and ``setup.py``
 --------------------------------
 
-Usually however, adding the ``tests/`` directory to the python path
+Usually, however, adding the ``tests/`` directory to the python path
 isn't desirable. Instead it would better to invoke the test straight
 from the module ``xxx``. To this end, simply place the following lines
 at the end of your package's ``__init__.py`` file::
@@ -324,13 +302,13 @@ from one in `numpy/linalg/tests/test_linalg.py
 
       ...
 
-  class TestSolve(LinalgTestCase, TestCase):
+  class TestSolve(LinalgTestCase):
       def do(self, a, b):
           x = linalg.solve(a, b)
           assert_almost_equal(b, dot(a, x))
           assert imply(isinstance(b, matrix), isinstance(x, matrix))
 
-  class TestInv(LinalgTestCase, TestCase):
+  class TestInv(LinalgTestCase):
       def do(self, a, b):
           a_inv = linalg.inv(a)
           assert_almost_equal(dot(a, a_inv), identity(asarray(a).shape[0]))
@@ -340,12 +318,6 @@ In this case, we wanted to test solving a linear algebra problem using
 matrices of several data types, using ``linalg.solve`` and
 ``linalg.inv``.  The common test cases (for single-precision,
 double-precision, etc. matrices) are collected in ``LinalgTestCase``.
-Note that ``LinalgTestCase`` is not descended from ``TestCase``--if it
-were, then nose would attempt to run ``LinalgTestCase.test_single``
-and ``LinalgTestCase.test_double``, which would fail because
-``LinalgTestCase`` has no ``do`` method.  Since ``TestSolve`` and
-``TestInv`` inherit from ``LinalgTestCase`` and ``TestCase``, nose
-will run ``test_single`` and ``test_double`` for each class.
 
 Known failures & skipping tests
 -------------------------------