[Python-checkins] CVS: python/dist/src/Lib/test README,1.6,1.7

[Fred L. Drake]

Update of /cvsroot/python/python/dist/src/Lib/test
In directory usw-pr-cvs1:/tmp/cvs-serv14199/Lib/test

Modified Files:
	README 
Log Message:

Update to reflect recent changes to regrtest and the new approaches to
testing using doctest and PyUnit.


Index: README
===================================================================
RCS file: /cvsroot/python/python/dist/src/Lib/test/README,v
retrieving revision 1.6
retrieving revision 1.7
diff -C2 -r1.6 -r1.7
*** README	2000/10/23 16:37:14	1.6
--- README	2001/05/23 04:57:49	1.7
***************
*** 9,20 ****
  If you add a new module to Python or modify the functionality of an existing
  module, you should write one or more test cases to exercise that new
! functionality.  The mechanics of how the test system operates are fairly
! straightforward.  When a test case is run, the output is compared with the
! expected output that is stored in .../Lib/test/output.  If the test runs to
! completion and the actual and expected outputs match, the test succeeds, if
! not, it fails.  If an ImportError or test_support.TestSkipped error is
! raised, the test is not run.
  
! You will be writing unit tests (isolated tests of functions and objects
  defined by the module) using white box techniques.  Unlike black box
  testing, where you only have the external interfaces to guide your test case
--- 9,23 ----
  If you add a new module to Python or modify the functionality of an existing
  module, you should write one or more test cases to exercise that new
! functionality.  There are different ways to do this within the regression
! testing facility provided with Python; any particular test should use only
! one of these options.  Each option requires writing a test module using the
! conventions of the the selected option:
! 
!     - PyUnit based tests
!     - doctest based tests
!     - "traditional" Python test modules
  
! Regardless of the mechanics of the testing approach you choose,
! you will be writing unit tests (isolated tests of functions and objects
  defined by the module) using white box techniques.  Unlike black box
  testing, where you only have the external interfaces to guide your test case
***************
*** 24,28 ****
--- 27,72 ----
  your regression test cases.
  
+ PyUnit based tests
+ 
+ The PyUnit framework is based on the ideas of unit testing as espoused
+ by Kent Beck and the Extreme Programming (XP) movement.  The specific
+ interface provided by the framework is tightly based on the JUnit
+ Java implementation of Beck's original SmallTalk test framework.  Please
+ see the documentation of the unittest module for detailed information on
+ the interface and general guidelines on writing PyUnit based tests.
+ 
+ The test_support helper module provides a single function for use by
+ PyUnit based tests in the Python regression testing framework:
+ run_unittest() takes a unittest.TestCase derived class as a parameter
+ and runs the tests defined in that class.  All test methods in the
+ Python regression framework have names that start with "test_" and use
+ lower-case names with words separated with underscores.
+ 
+ doctest based tests
+ 
+ Tests written to use doctest are actually part of the docstrings for
+ the module being tested.  Each test is written as a display of an
+ interactive session, including the Python prompts, statements that would
+ be typed by the user, and the output of those statements (including
+ tracebacks!).  The module in the test package is simply a wrapper that
+ causes doctest to run over the tests in the module.  The test for the
+ doctest module provides a convenient example:
+ 
+     import doctest
+     doctest.testmod(doctest, verbose=1)
  
+ See the documentation for the doctest module for information on
+ writing tests using the doctest framework.
+ 
+ "traditional" Python test modules
+ 
+ The mechanics of how the "traditional" test system operates are fairly
+ straightforward.  When a test case is run, the output is compared with the
+ expected output that is stored in .../Lib/test/output.  If the test runs to
+ completion and the actual and expected outputs match, the test succeeds, if
+ not, it fails.  If an ImportError or test_support.TestSkipped error is
+ raised, the test is not run.
+ 
+ 
  Executing Test Cases
  
***************
*** 35,38 ****
--- 79,86 ----
  
      ./python Lib/test/regrtest.py -g test_spam.py
+ 
+ (If your test does not generate any output when run successfully, this
+ step may be skipped; no file containing expected output will be needed
+ in this case.)
  
  Any time you modify test_spam.py you need to generate a new expected