svn+ssh://pythondev@svn.python.org/python/branches/p3yk
................
r55636 | neal.norwitz | 2007-05-29 00:06:39 -0700 (Tue, 29 May 2007) | 149 lines
Merged revisions 55506-55635 via svnmerge from
svn+ssh://pythondev@svn.python.org/python/trunk
........
r55507 | georg.brandl | 2007-05-22 07:28:17 -0700 (Tue, 22 May 2007) | 2 lines
Remove the "panel" module doc file which has been ignored since 1994.
........
r55522 | mark.hammond | 2007-05-22 19:04:28 -0700 (Tue, 22 May 2007) | 4 lines
Remove definition of PY_UNICODE_TYPE from pyconfig.h, allowing the
definition in unicodeobject.h to be used, giving us the desired
wchar_t in place of 'unsigned short'. As discussed on python-dev.
........
r55525 | neal.norwitz | 2007-05-22 23:35:32 -0700 (Tue, 22 May 2007) | 6 lines
Add -3 option to the interpreter to warn about features that are
deprecated and will be changed/removed in Python 3.0.
This patch is mostly from Anthony. I tweaked some format and added
a little doc.
........
r55527 | neal.norwitz | 2007-05-22 23:57:35 -0700 (Tue, 22 May 2007) | 1 line
Whitespace cleanup
........
r55528 | neal.norwitz | 2007-05-22 23:58:36 -0700 (Tue, 22 May 2007) | 1 line
Add a bunch more deprecation warnings for builtins that are going away in 3.0
........
r55549 | georg.brandl | 2007-05-24 09:49:29 -0700 (Thu, 24 May 2007) | 2 lines
shlex.split() now has an optional "posix" parameter.
........
r55550 | georg.brandl | 2007-05-24 10:33:33 -0700 (Thu, 24 May 2007) | 2 lines
Fix parameter passing.
........
r55555 | facundo.batista | 2007-05-24 10:50:54 -0700 (Thu, 24 May 2007) | 6 lines
Added an optional timeout parameter to urllib.ftpwrapper, with tests
(for this and a basic one, because there weren't any). Changed also
NEWS, but didn't find documentation for this function, assumed it
wasn't public...
........
r55563 | facundo.batista | 2007-05-24 13:01:59 -0700 (Thu, 24 May 2007) | 4 lines
Removed the .recv() in the test, is not necessary, and was
causing problems that didn't have anything to do with was
actually being tested...
........
r55564 | facundo.batista | 2007-05-24 13:51:19 -0700 (Thu, 24 May 2007) | 5 lines
Let's see if reading exactly what is written allow this live
test to pass (now I know why there were so few tests in ftp,
http, etc, :( ).
........
r55567 | facundo.batista | 2007-05-24 20:10:28 -0700 (Thu, 24 May 2007) | 4 lines
Trying to make the tests work in Windows and Solaris, everywhere
else just works
........
r55568 | facundo.batista | 2007-05-24 20:47:19 -0700 (Thu, 24 May 2007) | 4 lines
Fixing stupid error, and introducing a sleep, to see if the
other thread is awakened and finish sending data.
........
r55569 | facundo.batista | 2007-05-24 21:20:22 -0700 (Thu, 24 May 2007) | 4 lines
Commenting out the tests until find out who can test them in
one of the problematic enviroments.
........
r55570 | neal.norwitz | 2007-05-24 22:13:40 -0700 (Thu, 24 May 2007) | 2 lines
Get test passing again by commenting out the reference to the test class.
........
r55575 | vinay.sajip | 2007-05-25 00:05:59 -0700 (Fri, 25 May 2007) | 1 line
Updated docstring for SysLogHandler (#1720726).
........
r55576 | vinay.sajip | 2007-05-25 00:06:55 -0700 (Fri, 25 May 2007) | 1 line
Updated documentation for SysLogHandler (#1720726).
........
r55592 | brett.cannon | 2007-05-25 13:17:15 -0700 (Fri, 25 May 2007) | 3 lines
Remove direct call's to file's constructor and replace them with calls to
open() as ths is considered best practice.
........
r55601 | kristjan.jonsson | 2007-05-26 12:19:50 -0700 (Sat, 26 May 2007) | 1 line
Remove the rgbimgmodule from PCBuild8
........
r55602 | kristjan.jonsson | 2007-05-26 12:31:39 -0700 (Sat, 26 May 2007) | 1 line
Include <windows.h> after python.h, so that WINNT is properly set before windows.h is included. Fixes warnings in PC builds.
........
r55603 | walter.doerwald | 2007-05-26 14:04:13 -0700 (Sat, 26 May 2007) | 2 lines
Fix typo.
........
r55604 | peter.astrand | 2007-05-26 15:18:20 -0700 (Sat, 26 May 2007) | 1 line
Applied patch 1669481, slightly modified: Support close_fds on Win32
........
r55606 | neal.norwitz | 2007-05-26 21:08:54 -0700 (Sat, 26 May 2007) | 2 lines
Add the new function object attribute names from py3k.
........
r55617 | lars.gustaebel | 2007-05-27 12:49:30 -0700 (Sun, 27 May 2007) | 20 lines
Added errors argument to TarFile class that allows the user to
specify an error handling scheme for character conversion. Additional
scheme "utf-8" in read mode. Unicode input filenames are now
supported by design. The values of the pax_headers dictionary are now
limited to unicode objects.
Fixed: The prefix field is no longer used in PAX_FORMAT (in
conformance with POSIX).
Fixed: In read mode use a possible pax header size field.
Fixed: Strip trailing slashes from pax header name values.
Fixed: Give values in user-specified pax_headers precedence when
writing.
Added unicode tests. Added pax/regtype4 member to testtar.tar all
possible number fields in a pax header.
Added two chapters to the documentation about the different formats
tarfile.py supports and how unicode issues are handled.
........
r55618 | raymond.hettinger | 2007-05-27 22:23:22 -0700 (Sun, 27 May 2007) | 1 line
Explain when groupby() issues a new group.
........
r55634 | martin.v.loewis | 2007-05-28 21:01:29 -0700 (Mon, 28 May 2007) | 2 lines
Test pre-commit hook for a link to a .py file.
........
r55635 | martin.v.loewis | 2007-05-28 21:02:03 -0700 (Mon, 28 May 2007) | 2 lines
Revert 55634.
........
................
r55639 | neal.norwitz | 2007-05-29 00:58:11 -0700 (Tue, 29 May 2007) | 1 line
Remove sys.exc_{type,exc_value,exc_traceback}
................
r55641 | neal.norwitz | 2007-05-29 01:03:50 -0700 (Tue, 29 May 2007) | 1 line
Missed one sys.exc_type. I wonder why exc_{value,traceback} were already gone
................
r55642 | neal.norwitz | 2007-05-29 01:08:33 -0700 (Tue, 29 May 2007) | 1 line
Missed more doc for sys.exc_* attrs.
................
r55643 | neal.norwitz | 2007-05-29 01:18:19 -0700 (Tue, 29 May 2007) | 1 line
Remove sys.exc_clear()
................
r55665 | guido.van.rossum | 2007-05-29 19:45:43 -0700 (Tue, 29 May 2007) | 4 lines
Make None, True, False keywords.
We can now also delete all the other places that explicitly forbid
assignment to None, but I'm not going to bother right now.
................
r55666 | guido.van.rossum | 2007-05-29 20:01:51 -0700 (Tue, 29 May 2007) | 3 lines
Found another place that needs check for forbidden names.
Fixed test_syntax.py accordingly (it helped me find that one).
................
r55668 | guido.van.rossum | 2007-05-29 20:41:48 -0700 (Tue, 29 May 2007) | 2 lines
Mark None, True, False as keywords.
................
r55673 | neal.norwitz | 2007-05-29 23:28:25 -0700 (Tue, 29 May 2007) | 3 lines
Get the dis module working on modules again after changing dicts
to not return lists and also new-style classes. Add a test.
................
r55674 | neal.norwitz | 2007-05-29 23:35:45 -0700 (Tue, 29 May 2007) | 1 line
Umm, it helps to add the module that the test uses
................
r55675 | neal.norwitz | 2007-05-29 23:53:05 -0700 (Tue, 29 May 2007) | 4 lines
Try to fix up all the other places that were assigning to True/False.
There's at least one more problem in test.test_xmlrpc. I have other
changes in that file and that should be fixed soon (I hope).
................
r55679 | neal.norwitz | 2007-05-30 00:31:55 -0700 (Wed, 30 May 2007) | 1 line
Fix up another place that was assigning to True/False.
................
r55688 | brett.cannon | 2007-05-30 14:19:47 -0700 (Wed, 30 May 2007) | 2 lines
Ditch MimeWriter.
................
r55692 | brett.cannon | 2007-05-30 14:52:00 -0700 (Wed, 30 May 2007) | 2 lines
Remove the mimify module.
................
r55707 | guido.van.rossum | 2007-05-31 05:08:45 -0700 (Thu, 31 May 2007) | 2 lines
Backport the addition of show_code() to dis.py -- it's too handy.
................
r55708 | guido.van.rossum | 2007-05-31 06:22:57 -0700 (Thu, 31 May 2007) | 7 lines
Fix a fairly long-standing bug in the check for assignment to None (and other
keywords, these days). In 2.5, you could write foo(None=1) without getting
a SyntaxError (although foo()'s definition would have to use **kwds to avoid
getting a runtime error complaining about an unknown keyword of course).
This ought to be backported to 2.5.2 or at least 2.6.
................
r55724 | brett.cannon | 2007-05-31 19:32:41 -0700 (Thu, 31 May 2007) | 2 lines
Remove the cfmfile.
................
r55727 | neal.norwitz | 2007-05-31 22:19:44 -0700 (Thu, 31 May 2007) | 1 line
Remove reload() builtin.
................
r55729 | neal.norwitz | 2007-05-31 22:51:30 -0700 (Thu, 31 May 2007) | 59 lines
Merged revisions 55636-55728 via svnmerge from
svn+ssh://pythondev@svn.python.org/python/trunk
........
r55637 | georg.brandl | 2007-05-29 00:16:47 -0700 (Tue, 29 May 2007) | 2 lines
Fix rst markup.
........
r55638 | neal.norwitz | 2007-05-29 00:51:39 -0700 (Tue, 29 May 2007) | 1 line
Fix typo in doc
........
r55671 | neal.norwitz | 2007-05-29 21:53:41 -0700 (Tue, 29 May 2007) | 1 line
Fix indentation (whitespace only).
........
r55676 | thomas.heller | 2007-05-29 23:58:30 -0700 (Tue, 29 May 2007) | 1 line
Fix compiler warnings.
........
r55677 | thomas.heller | 2007-05-30 00:01:25 -0700 (Wed, 30 May 2007) | 2 lines
Correct the name of a field in the WIN32_FIND_DATAA and WIN32_FIND_DATAW structures.
Closes bug #1726026.
........
r55686 | brett.cannon | 2007-05-30 13:46:26 -0700 (Wed, 30 May 2007) | 2 lines
Have MimeWriter raise a DeprecationWarning as per PEP 4 and its documentation.
........
r55690 | brett.cannon | 2007-05-30 14:48:58 -0700 (Wed, 30 May 2007) | 3 lines
Have mimify raise a DeprecationWarning. The docs and PEP 4 have listed the
module as deprecated for a while.
........
r55696 | brett.cannon | 2007-05-30 15:24:28 -0700 (Wed, 30 May 2007) | 2 lines
Have md5 raise a DeprecationWarning as per PEP 4.
........
r55705 | neal.norwitz | 2007-05-30 21:14:22 -0700 (Wed, 30 May 2007) | 1 line
Add some spaces in the example code.
........
r55716 | brett.cannon | 2007-05-31 12:20:00 -0700 (Thu, 31 May 2007) | 2 lines
Have the sha module raise a DeprecationWarning as specified in PEP 4.
........
r55719 | brett.cannon | 2007-05-31 12:40:42 -0700 (Thu, 31 May 2007) | 2 lines
Cause buildtools to raise a DeprecationWarning.
........
r55721 | brett.cannon | 2007-05-31 13:01:11 -0700 (Thu, 31 May 2007) | 2 lines
Have cfmfile raise a DeprecationWarning as per PEP 4.
........
r55726 | neal.norwitz | 2007-05-31 21:56:47 -0700 (Thu, 31 May 2007) | 1 line
Mail if there is an installation failure.
........
................
r55730 | neal.norwitz | 2007-05-31 23:22:07 -0700 (Thu, 31 May 2007) | 2 lines
Remove the code that was missed in rev 55303.
................
r55738 | neal.norwitz | 2007-06-01 19:10:43 -0700 (Fri, 01 Jun 2007) | 1 line
Fix doc breakage
................
r55741 | neal.norwitz | 2007-06-02 00:41:58 -0700 (Sat, 02 Jun 2007) | 1 line
Remove timing module (plus some remnants of other modules).
................
r55742 | neal.norwitz | 2007-06-02 00:51:44 -0700 (Sat, 02 Jun 2007) | 1 line
Remove posixfile module (plus some remnants of other modules).
................
r55744 | neal.norwitz | 2007-06-02 10:18:56 -0700 (Sat, 02 Jun 2007) | 1 line
Fix doc breakage.
................
r55745 | neal.norwitz | 2007-06-02 11:32:16 -0700 (Sat, 02 Jun 2007) | 1 line
Make a whatsnew 3.0 template.
................
r55754 | neal.norwitz | 2007-06-03 23:24:18 -0700 (Sun, 03 Jun 2007) | 1 line
SF #1730441, os._execvpe raises UnboundLocal due to new try/except semantics
................
r55755 | neal.norwitz | 2007-06-03 23:26:00 -0700 (Sun, 03 Jun 2007) | 1 line
Get rid of extra whitespace
................
r55794 | guido.van.rossum | 2007-06-06 15:29:22 -0700 (Wed, 06 Jun 2007) | 3 lines
Make this compile in GCC 2.96, which does not allow interspersing
declarations and code.
................
+++++++++++++++++++++++++++++++
Writing Python Regression Tests
+++++++++++++++++++++++++++++++
:Author: Skip Montanaro
:Contact: skip@mojam.com
Introduction
============
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 selected option:
- unittest_ 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
writing, in white box testing you can see the code being tested and tailor
your test cases to exercise it more completely. In particular, you will be
able to refer to the C and Python code in the CVS repository when writing
your regression test cases.
.. _unittest: http://www.python.org/doc/current/lib/module-unittest.html
.. _doctest: http://www.python.org/doc/current/lib/module-doctest.html
unittest-based tests
------------------
The unittest_ 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 unittest-based tests.
The test_support helper module provides a function for use by
unittest-based tests in the Python regression testing framework,
``run_unittest()``. This is the primary way of running tests in the
standard library. You can pass it any number of the following:
- classes derived from or instances of ``unittest.TestCase`` or
``unittest.TestSuite``. These will be handed off to unittest for
converting into a proper TestSuite instance.
- a string; this must be a key in sys.modules. The module associated with
that string will be scanned by ``unittest.TestLoader.loadTestsFromModule``.
This is usually seen as ``test_support.run_unittest(__name__)`` in a test
module's ``test_main()`` function. This has the advantage of picking up
new tests automatically, without you having to add each new test case
manually.
All test methods in the Python regression framework have names that
start with "``test_``" and use lower-case names with words separated with
underscores.
Test methods should *not* have docstrings! The unittest module prints
the docstring if there is one, but otherwise prints the function name
and the full class name. When there's a problem with a test, the
latter information makes it easier to find the source for the test
than the docstring.
All unittest-based tests in the Python test suite use boilerplate that
looks like this (with minor variations)::
import unittest
from test import test_support
class MyTestCase1(unittest.TestCase):
# Define setUp and tearDown only if needed
def setUp(self):
unittest.TestCase.setUp(self)
... additional initialization...
def tearDown(self):
... additional finalization...
unittest.TestCase.tearDown(self)
def test_feature_one(self):
# Testing feature one
...unit test for feature one...
def test_feature_two(self):
# Testing feature two
...unit test for feature two...
...etc...
class MyTestCase2(unittest.TestCase):
...same structure as MyTestCase1...
...etc...
def test_main():
test_support.run_unittest(__name__)
if __name__ == "__main__":
test_main()
This has the advantage that it allows the unittest module to be used
as a script to run individual tests as well as working well with the
regrtest framework.
.. _Extreme Programming: http://www.extremeprogramming.org/
.. _JUnit: http://www.junit.org/
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, although only the exception msg needs to be retained then).
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 difflib module
provides a convenient example::
import difflib
from test import test_support
test_support.run_doctest(difflib)
If the test is successful, nothing is written to stdout (so you should not
create a corresponding output/test_difflib file), but running regrtest
with -v will give a detailed report, the same as if passing -v to doctest.
A second argument can be passed to run_doctest to tell doctest to search
``sys.argv`` for -v instead of using test_support's idea of verbosity. This
is useful for writing doctest-based tests that aren't simply running a
doctest'ed Lib module, but contain the doctests themselves. Then at
times you may want to run such a test directly as a doctest, independent
of the regrtest framework. The tail end of test_descrtut.py is a good
example::
def test_main(verbose=None):
from test import test_support, test_descrtut
test_support.run_doctest(test_descrtut, verbose)
if __name__ == "__main__":
test_main(1)
If run via regrtest, ``test_main()`` is called (by regrtest) without
specifying verbose, and then test_support's idea of verbosity is used. But
when run directly, ``test_main(1)`` is called, and then doctest's idea of
verbosity is used.
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
====================
If you are writing test cases for module spam, you need to create a file
in .../Lib/test named test_spam.py. In addition, if the tests are expected
to write to stdout during a successful run, you also need to create an
expected output file in .../Lib/test/output named test_spam ("..."
represents the top-level directory in the Python source tree, the directory
containing the configure script). If needed, generate the initial version
of the test output file by executing::
./python Lib/test/regrtest.py -g test_spam.py
from the top-level directory.
Any time you modify test_spam.py you need to generate a new expected
output file. Don't forget to desk check the generated output to make sure
it's really what you expected to find! All in all it's usually better
not to have an expected-out file (note that doctest- and unittest-based
tests do not).
To run a single test after modifying a module, simply run regrtest.py
without the -g flag::
./python Lib/test/regrtest.py test_spam.py
While debugging a regression test, you can of course execute it
independently of the regression testing framework and see what it prints::
./python Lib/test/test_spam.py
To run the entire test suite:
- [UNIX, + other platforms where "make" works] Make the "test" target at the
top level::
make test
- [WINDOWS] Run rt.bat from your PCBuild directory. Read the comments at
the top of rt.bat for the use of special -d, -O and -q options processed
by rt.bat.
- [OTHER] You can simply execute the two runs of regrtest (optimized and
non-optimized) directly::
./python Lib/test/regrtest.py
./python -O Lib/test/regrtest.py
But note that this way picks up whatever .pyc and .pyo files happen to be
around. The makefile and rt.bat ways run the tests twice, the first time
removing all .pyc and .pyo files from the subtree rooted at Lib/.
Test cases generate output based upon values computed by the test code.
When executed, regrtest.py compares the actual output generated by executing
the test case with the expected output and reports success or failure. It
stands to reason that if the actual and expected outputs are to match, they
must not contain any machine dependencies. This means your test cases
should not print out absolute machine addresses (e.g. the return value of
the id() builtin function) or floating point numbers with large numbers of
significant digits (unless you understand what you are doing!).
Test Case Writing Tips
======================
Writing good test cases is a skilled task and is too complex to discuss in
detail in this short document. Many books have been written on the subject.
I'll show my age by suggesting that Glenford Myers' `"The Art of Software
Testing"`_, published in 1979, is still the best introduction to the subject
available. It is short (177 pages), easy to read, and discusses the major
elements of software testing, though its publication predates the
object-oriented software revolution, so doesn't cover that subject at all.
Unfortunately, it is very expensive (about $100 new). If you can borrow it
or find it used (around $20), I strongly urge you to pick up a copy.
The most important goal when writing test cases is to break things. A test
case that doesn't uncover a bug is much less valuable than one that does.
In designing test cases you should pay attention to the following:
* Your test cases should exercise all the functions and objects defined
in the module, not just the ones meant to be called by users of your
module. This may require you to write test code that uses the module
in ways you don't expect (explicitly calling internal functions, for
example - see test_atexit.py).
* You should consider any boundary values that may tickle exceptional
conditions (e.g. if you were writing regression tests for division,
you might well want to generate tests with numerators and denominators
at the limits of floating point and integer numbers on the machine
performing the tests as well as a denominator of zero).
* You should exercise as many paths through the code as possible. This
may not always be possible, but is a goal to strive for. In
particular, when considering if statements (or their equivalent), you
want to create test cases that exercise both the true and false
branches. For loops, you should create test cases that exercise the
loop zero, one and multiple times.
* You should test with obviously invalid input. If you know that a
function requires an integer input, try calling it with other types of
objects to see how it responds.
* You should test with obviously out-of-range input. If the domain of a
function is only defined for positive integers, try calling it with a
negative integer.
* If you are going to fix a bug that wasn't uncovered by an existing
test, try to write a test case that exposes the bug (preferably before
fixing it).
* If you need to create a temporary file, you can use the filename in
``test_support.TESTFN`` to do so. It is important to remove the file
when done; other tests should be able to use the name without cleaning
up after your test.
.. _"The Art of Software Testing":
http://www.amazon.com/exec/obidos/ISBN=0471043281
Regression Test Writing Rules
=============================
Each test case is different. There is no "standard" form for a Python
regression test case, though there are some general rules (note that
these mostly apply only to the "classic" tests; unittest_- and doctest_-
based tests should follow the conventions natural to those frameworks)::
* If your test case detects a failure, raise ``TestFailed`` (found in
``test.test_support``).
* Import everything you'll need as early as possible.
* If you'll be importing objects from a module that is at least
partially platform-dependent, only import those objects you need for
the current test case to avoid spurious ``ImportError`` exceptions
that prevent the test from running to completion.
* Print all your test case results using the ``print`` statement. For
non-fatal errors, print an error message (or omit a successful
completion print) to indicate the failure, but proceed instead of
raising ``TestFailed``.
* Use ``assert`` sparingly, if at all. It's usually better to just print
what you got, and rely on regrtest's got-vs-expected comparison to
catch deviations from what you expect. ``assert`` statements aren't
executed at all when regrtest is run in -O mode; and, because they
cause the test to stop immediately, can lead to a long & tedious
test-fix, test-fix, test-fix, ... cycle when things are badly broken
(and note that "badly broken" often includes running the test suite
for the first time on new platforms or under new implementations of
the language).
Miscellaneous
=============
There is a test_support module in the test package you can import for
your test case. Import this module using either::
import test.test_support
or::
from test import test_support
test_support provides the following useful objects:
* ``TestFailed`` - raise this exception when your regression test detects
a failure.
* ``TestSkipped`` - raise this if the test could not be run because the
platform doesn't offer all the required facilities (like large
file support), even if all the required modules are available.
* ``ResourceDenied`` - this is raised when a test requires a resource that
is not available. Primarily used by 'requires'.
* ``verbose`` - you can use this variable to control print output. Many
modules use it. Search for "verbose" in the test_*.py files to see
lots of examples.
* ``forget(module_name)`` - attempts to cause Python to "forget" that it
loaded a module and erase any PYC files.
* ``is_resource_enabled(resource)`` - Returns a boolean based on whether
the resource is enabled or not.
* ``requires(resource [, msg])`` - if the required resource is not
available the ResourceDenied exception is raised.
* ``verify(condition, reason='test failed')``. Use this instead of::
assert condition[, reason]
``verify()`` has two advantages over ``assert``: it works even in -O
mode, and it raises ``TestFailed`` on failure instead of
``AssertionError``.
* ``have_unicode`` - true if Unicode is available, false otherwise.
* ``is_jython`` - true if the interpreter is Jython, false otherwise.
* ``TESTFN`` - a string that should always be used as the filename when
you need to create a temp file. Also use ``try``/``finally`` to
ensure that your temp files are deleted before your test completes.
Note that you cannot unlink an open file on all operating systems, so
also be sure to close temp files before trying to unlink them.
* ``sortdict(dict)`` - acts like ``repr(dict.items())``, but sorts the
items first. This is important when printing a dict value, because
the order of items produced by ``dict.items()`` is not defined by the
language.
* ``findfile(file)`` - you can call this function to locate a file
somewhere along sys.path or in the Lib/test tree - see
test_linuxaudiodev.py for an example of its use.
* ``fcmp(x,y)`` - you can call this function to compare two floating
point numbers when you expect them to only be approximately equal
withing a fuzz factor (``test_support.FUZZ``, which defaults to 1e-6).
* ``check_syntax_error(testcase, statement)`` - make sure that the
statement is *not* correct Python syntax.
Python and C statement coverage results are currently available at
http://www.musi-cal.com/~skip/python/Python/dist/src/
As of this writing (July, 2000) these results are being generated nightly.
You can refer to the summaries and the test coverage output files to see
where coverage is adequate or lacking and write test cases to beef up the
coverage.
Some Non-Obvious regrtest Features
==================================
* Automagic test detection: When you create a new test file
test_spam.py, you do not need to modify regrtest (or anything else)
to advertise its existence. regrtest searches for and runs all
modules in the test directory with names of the form test_xxx.py.
* Miranda output: If, when running test_spam.py, regrtest does not
find an expected-output file test/output/test_spam, regrtest
pretends that it did find one, containing the single line
test_spam
This allows new tests that don't expect to print anything to stdout
to not bother creating expected-output files.
* Two-stage testing: To run test_spam.py, regrtest imports test_spam
as a module. Most tests run to completion as a side-effect of
getting imported. After importing test_spam, regrtest also executes
``test_spam.test_main()``, if test_spam has a ``test_main`` attribute.
This is rarely required with the "traditional" Python tests, and
you shouldn't create a module global with name test_main unless
you're specifically exploiting this gimmick. This usage does
prove useful with unittest-based tests as well, however; defining
a ``test_main()`` which is run by regrtest and a script-stub in the
test module ("``if __name__ == '__main__': test_main()``") allows
the test to be used like any other Python test and also work
with the unittest.py-as-a-script approach, allowing a developer
to run specific tests from the command line.