tcltest.n

来自「tcl是工具命令语言」· N 代码 · 共 1,066 行 · 第 1/3 页

the constraints that caused tests to be skipped, and the
number of tests skipped for each is also printed.  Also,
messages are printed if it appears that evaluation of
a test file has caused any temporary files to be left
behind in [\fBconfigure -tmpdir\fR].
.PP
Having completed and summarized all selected test files,
[\fBrunAllTests\fR] then recursively acts on subdirectories
of [\fBconfigure -testdir\fR].  All subdirectories that
match any of the patterns in [\fBconfigure -relateddir\fR]
and do not match any of the patterns in
[\fBconfigure -asidefromdir\fR] are examined.  If
a file named \fBall.tcl\fR is found in such a directory,
it will be [\fBsource\fR]d in the caller's context.
Whether or not an examined directory contains an
\fBall.tcl\fR file, its subdirectories are also scanned
against the [\fBconfigure -relateddir\fR] and
[\fBconfigure -asidefromdir\fR] patterns.  In this way,
many directories in a directory tree can have all their
test files evaluated by a single [\fBrunAllTests\fR]
command.
.SH "CONFIGURABLE OPTIONS"
The [\fBconfigure\fR] command is used to set and query the configurable
options of \fBtcltest\fR.  The valid options are:
.TP
\fB-singleproc \fIboolean\fR
Controls whether or not [\fBrunAllTests\fR] spawns a child process for
each test file.  No spawning when \fIboolean\fR is true.  Default
value is false.
.TP
\fB-debug \fIlevel\fR
Sets the debug level to \fIlevel\fR, an integer value indicating how
much debugging information should be printed to stdout.  Note that
debug messages always go to stdout, independent of the value of
[\fBconfigure -outfile\fR].  Default value is 0.  Levels are defined as:
.RS
.IP 0
Do not display any debug information.
.IP 1
Display information regarding whether a test is skipped because it
doesn't match any of the tests that were specified using by
[\fBconfigure -match\fR] (userSpecifiedNonMatch) or matches any of
the tests specified by [\fBconfigure -skip\fR] (userSpecifiedSkip).  Also
print warnings about possible lack of cleanup or balance in test files.
.IP 2
Display the flag array parsed by the command line processor, the
contents of the ::env array, and all user-defined variables that exist
in the current namespace as they are used.
.IP 3
Display information regarding what individual procs in the test
harness are doing.
.RE
.TP
\fB-verbose \fIlevel\fR
Sets the type of output verbosity desired to \fIlevel\fR,
a list of zero or more of the elements \fBbody\fR, \fBpass\fR,
\fBskip\fR, \fBstart\fR, and \fBerror\fR.  Default value is \fBbody\fR.
Levels are defined as: 
.RS
.IP "body (b)"
Display the body of failed tests
.IP "pass (p)"
Print output when a test passes
.IP "skip (s)"
Print output when a test is skipped
.IP "start (t)"
Print output whenever a test starts
.IP "error (e)"
Print errorInfo and errorCode, if they exist, when a test return code
does not match its expected return code
.RE
The single letter abbreviations noted above are also recognized
so that [\fBconfigure -verbose pt\fR] is the same as
[\fBconfigure -verbose  {pass start}\fR].
.TP
\fB-preservecore \fIlevel\fR
Sets the core preservation level to \fIlevel\fR.  This level
determines how stringent checks for core files are.  Default
value is 0.  Levels are defined as:
.RS
.IP 0
No checking - do not check for core files at the end of each test
command, but do check for them in [\fBrunAllTests\fR] after all
test files have been evaluated.
.IP 1
Also check for core files at the end of each [\fBtest\fR] command.
.IP 2
Check for core files at all times described above, and save a 
copy of each core file produced in [\fBconfigure -tmpdir\fR].
.RE
.TP
\fB-limitconstraints \fIboolean\fR
Sets the mode by which [\fBtest\fR] honors constraints as described
in \fBTESTS\fR above.  Default value is false.
.TP
\fB-constraints \fIlist\fR
Sets all the constraints in \fIlist\fR to true.  Also used in
combination with [\fBconfigure -limitconstraints true\fR] to control an
alternative constraint mode as described in \fBTESTS\fR above.
Default value is an empty list.
.TP
\fB-tmpdir \fIdirectory\fR
Sets the temporary directory to be used by [\fBmakeFile\fR],
[\fBmakeDirectory\fR], [\fBviewFile\fR], [\fBremoveFile\fR], 
and [\fBremoveDirectory\fR] as the default directory where
temporary files and directories created by test files should
be created.  Default value is [\fBworkingDirectory\fR].
.TP
\fB-testdir \fIdirectory\fR
Sets the directory searched by [\fBrunAllTests\fR] for test files
and subdirectories.  Default value is [\fBworkingDirectory\fR].
.TP
\fB-file \fIpatternList\fR
Sets the list of patterns used by [\fBrunAllTests\fR] to determine
what test files to evaluate.  Default value is \fB*.test\fR.
.TP
\fB-notfile \fIpatternList\fR
Sets the list of patterns used by [\fBrunAllTests\fR] to determine
what test files to skip.  Default value is \fBl.*.test\fR, so
that any SCCS lock files are skipped.
.TP
\fB-relateddir \fIpatternList\fR
Sets the list of patterns used by [\fBrunAllTests\fR] to determine
what subdirectories to search for an \fBall.tcl\fR file.  Default
value is \fB*\fR.
.TP
\fB-asidefromdir \fIpatternList\fR
Sets the list of patterns used by [\fBrunAllTests\fR] to determine
what subdirectories to skip when searching for an \fBall.tcl\fR file.
Default value is an empty list.
.TP
\fB-match \fIpatternList\fR
Set the list of patterns used by [\fBtest\fR] to determine whether
a test should be run.  Default value is \fB*\fR.
.TP
\fB-skip \fIpatternList\fR
Set the list of patterns used by [\fBtest\fR] to determine whether
a test should be skipped.  Default value is an empty list.
.TP
\fB-load \fIscript\fR
Sets a script to be evaluated by [\fBloadTestedCommands\fR].
Default value is an empty script.
.TP
\fB-loadfile \fIfilename\fR
Sets the filename from which to read a script to be evaluated
by [\fBloadTestedCommands\fR].  This is an alternative to
\fB-load\fR.  They cannot be used together.
.TP
\fB-outfile \fIfilename\fR 
Sets the file to which all output produced by tcltest should be
written.  A file named \fIfilename\fR will be [\fBopen\fR]ed for writing,
and the resulting channel will be set as the value of [\fBoutputChannel\fR].
.TP
\fB-errfile \fIfilename\fR
Sets the file to which all error output produced by tcltest
should be written.  A file named \fIfilename\fR will be [\fBopen\fR]ed
for writing, and the resulting channel will be set as the value
of [\fBerrorChannel\fR].
.SH "CREATING TEST SUITES WITH TCLTEST"
.PP
The fundamental element of a test suite is the individual [\fBtest\fR]
command.  We begin with several examples.
.IP [1]
Test of a script that returns normally.
.CS
test example-1.0 {normal return} {
    format %s value
} value
.CE
.IP [2]
Test of a script that requires context setup and cleanup.  Note the
bracing and indenting style that avoids any need for line continuation.
.CS
test example-1.1 {test file existence} -setup {
    set file [makeFile {} test]
} -body {
    file exists $file
} -cleanup {
    removeFile test
} -result 1
.CE
.IP [3]
Test of a script that raises an error.
.CS
test example-1.2 {error return} -body {
    error message
} -returnCodes error -result message
.CE
.IP [4]
Test with a constraint.
.CS
test example-1.3 {user owns created files} -constraints {
    unix
} -setup {
    set file [makeFile {} test]
} -body {
    file attributes $file -owner
} -cleanup {
    removeFile test
} -result $::tcl_platform(user)
.CE
.PP
At the next higher layer of organization, several [\fBtest\fR] commands
are gathered together into a single test file.  Test files should have
names with the \fB.test\fR extension, because that is the default pattern
used by [\fBrunAllTests\fR] to find test files.  It is a good rule of
thumb to have one test file for each source code file of your project.
It is good practice to edit the test file and the source code file
together, keeping tests synchronized with code changes.
.PP 
Most of the code in the test file should be the [\fBtest\fR] commands.
Use constraints to skip tests, rather than conditional evaluation
of [\fBtest\fR].  That is, do this:
.IP [5]
.CS
testConstraint X [expr $myRequirement]
test goodConditionalTest {} X {
    # body
} result
.CE
and do not do this:
.IP [6]
.CS
if $myRequirement {
    test badConditionalTest {} {
	#body
    } result
}
.CE
.PP
Use the \fB-setup\fR and \fB-cleanup\fR options to establish and release
all context requirements of the test body.  Do not make tests depend on
prior tests in the file.  Those prior tests might be skipped.  If several
consecutive tests require the same context, the appropriate setup
and cleanup scripts may be stored in variable for passing to each tests
\fB-setup\fR and \fB-cleanup\fR options.  This is a better solution than
performing setup outside of [\fBtest\fR] commands, because the setup will
only be done if necessary, and any errors during setup will be reported,
and not cause the test file to abort.
.PP
A test file should be able to be combined with other test files and not
interfere with them, even when [\fBconfigure -singleproc 1\fR] causes
all files to be evaluated in a common interpreter.  A simple way to
achieve this is to have your tests define all their commands and variables
in a namespace that is deleted when the test file evaluation is complete.
A good namespace to use is a child namespace \fBtest\fR of the namespace
of the module you are testing.
.PP
A test file should also be able to be evaluated directly as a script,
not depending on being called by a master [\fBrunAllTests\fR].  This
means that each test file should process command line arguments to give
the tester all the configuration control that \fBtcltest\fR provides.
.PP
After all [\fBtest\fR]s in a test file, the command [\fBcleanupTests\fR]
should be called.
.IP [7]
Here is a sketch of a sample test file illustrating those points:
.CS
package require tcltest 2.2
eval tcltest::configure $argv
package require example
namespace eval ::example::test {
    namespace import ::tcltest::*
    testConstraint X [expr {...}]
    variable SETUP {#common setup code}
    variable CLEANUP {#common cleanup code}
    test example-1 {} -setup $SETUP {
	# First test
    } -cleanup $CLEANUP -result {...}
    test example-2 {} -constraints X -setup $SETUP {
	# Second test; constrained
    } -cleanup $CLEANUP -result {...}
    test example-3 {} {
	# Third test; no context required
    } {...}
    cleanupTests
}
namespace delete ::example::test
.CE
.PP
The next level of organization is a full test suite, made up of several
test files.  One script is used to control the entire suite.  The
basic function of this script is to call [\fBrunAllTests\fR] after
doing any necessary setup.  This script is usually named \fBall.tcl\fR
because that's the default name used by [\fBrunAllTests\fR] when combining
multiple test suites into one testing run.
.IP [8]
Here is a sketch of a sample test suite master script:
.CS
package require Tcl 8.4
package require tcltest 2.2
package require example
tcltest::configure -testdir \
        [file dirname [file normalize [info script]]]
eval tcltest::configure $argv
tcltest::runAllTests
.CE
.SH COMPATIBILITY
.PP
A number of commands and variables in the \fB::tcltest\fR namespace
provided by earlier releases of \fBtcltest\fR have not been documented
here.  They are no longer part of the supported public interface of
\fBtcltest\fR and should not be used in new test suites.  However,
to continue to support existing test suites written to the older
interface specifications, many of those deprecated commands and
variables still work as before.  For example, in many circumstances,
[\fBconfigure\fR] will be automatically called shortly after
[\fBpackage require tcltest 2.1\fR] succeeds with arguments
from the variable \fB::argv\fR.  This is to support test suites
that depend on the old behavior that \fBtcltest\fR was automatically
configured from command line arguments.  New test files should not
depend on this, but should explicitly include
.CS
eval tcltest::configure $::argv
.CE
to establish a configuration from command line arguments.
.SH "KNOWN ISSUES"
There are two known issues related to nested evaluations of [\fBtest\fR].  
The first issue relates to the stack level in which test scripts are
executed.  Tests nested within other tests may be executed at the same
stack level as the outermost test.  For example, in the following code: 
.CS
test level-1.1 {level 1} {
    -body {
        test level-2.1 {level 2} {
        }
    }
}
.CE
any script executed in level-2.1 may be executed at the same stack
level as the script defined for level-1.1.  
.PP
In addition, while two [\fBtest\fR]s have been run, results will only
be reported by [\fBcleanupTests\fR] for tests at the same level as
test level-1.1.  However, test results for all tests run prior to
level-1.1 will be available when test level-2.1 runs.  What this
means is that if you try to access the test results for test level-2.1,
it will may say that 'm' tests have run, 'n' tests have
been skipped, 'o' tests have passed and 'p' tests have failed,
where 'm', 'n', 'o', and 'p' refer to tests that were run at the
same test level as test level-1.1. 
.PP
Implementation of output and error comparison in the test command
depends on usage of puts in your application code.  Output is
intercepted by redefining the puts command while the defined test
script is being run.  Errors thrown by C procedures or printed
directly from C applications will not be caught by the test command.
Therefore, usage of the \fB-output\fR and \fB-errorOuput\fR
options to [\fBtest\fR] is useful only for pure Tcl applications
that use [\fBputs\fR] to produce output. 

.SH KEYWORDS
test, test harness, test suite