diff options
author | dkf <donal.k.fellows@manchester.ac.uk> | 2004-10-27 14:43:09 (GMT) |
---|---|---|
committer | dkf <donal.k.fellows@manchester.ac.uk> | 2004-10-27 14:43:09 (GMT) |
commit | 4955bdc67b8a5c3d9d12cf70cfe0b73c8a4f4ca8 (patch) | |
tree | 7a733c8f49dc66ae55cca35e7652f5bb0b1c51c6 /doc/tcltest.n | |
parent | 45beb64f7dcb09a6ce83532702bca760f72e6f4d (diff) | |
download | tcl-4955bdc67b8a5c3d9d12cf70cfe0b73c8a4f4ca8.zip tcl-4955bdc67b8a5c3d9d12cf70cfe0b73c8a4f4ca8.tar.gz tcl-4955bdc67b8a5c3d9d12cf70cfe0b73c8a4f4ca8.tar.bz2 |
Finished user-level documentation backport
Diffstat (limited to 'doc/tcltest.n')
-rw-r--r-- | doc/tcltest.n | 44 |
1 files changed, 22 insertions, 22 deletions
diff --git a/doc/tcltest.n b/doc/tcltest.n index b019def..64b3dd4 100644 --- a/doc/tcltest.n +++ b/doc/tcltest.n @@ -8,7 +8,7 @@ '\" See the file "license.terms" for information on usage and redistribution '\" of this file, and for a DISCLAIMER OF ALL WARRANTIES. '\" -'\" RCS: @(#) $Id: tcltest.n,v 1.38.2.4 2004/02/18 01:43:49 dgp Exp $ +'\" RCS: @(#) $Id: tcltest.n,v 1.38.2.5 2004/10/27 14:43:13 dkf Exp $ '\" .so man.macros .TH "tcltest" n 2.2 tcltest "Tcl Bundled Packages" @@ -378,7 +378,7 @@ also influence how [\fBtest\fR] operates. The valid options for [\fBtest\fR] are summarized: .CS .ta 0.8i -test \fIname\fR \fIdescription\fR +\fBtest\fR \fIname\fR \fIdescription\fR ?-constraints \fIkeywordList|expression\fR? ?-setup \fIsetupScript\fR? ?-body \fItestScript\fR? @@ -663,7 +663,7 @@ only constraints from the [\fBconfigure -constraints\fR] list are run; all others are skipped. For example, one might set up a configuration with .CS -configure -constraints knownBug \e +\fBconfigure\fR -constraints knownBug \e -limitconstraints true \e -verbose pass .CE @@ -683,7 +683,7 @@ that match any of the patterns in [\fBconfigure -file\fR] and match none of the patterns in [\fBconfigure -notfile\fR] is generated and sorted. Then each file will be evaluated in turn. If [\fBconfigure -singleproc\fR] is true, then each file will -be [\fBsource\fR]d in the caller's context. If if is false, +be [\fBsource\fR]d in the caller's context. If it is false, then a copy of [\fBinterpreter\fR] will be [\fBexec\fR]d to evaluate each file. The multi-process operation is useful when testing can cause errors so severe that a process @@ -873,7 +873,7 @@ command. We begin with several examples. .IP [1] Test of a script that returns normally. .CS -test example-1.0 {normal return} { +\fBtest\fR example-1.0 {normal return} { format %s value } value .CE @@ -881,7 +881,7 @@ test example-1.0 {normal return} { 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 { +\fBtest\fR example-1.1 {test file existence} -setup { set file [makeFile {} test] } -body { file exists $file @@ -892,14 +892,14 @@ test example-1.1 {test file existence} -setup { .IP [3] Test of a script that raises an error. .CS -test example-1.2 {error return} -body { +\fBtest\fR 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 { +\fBtest\fR example-1.3 {user owns created files} -constraints { unix } -setup { set file [makeFile {} test] @@ -923,8 +923,8 @@ 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 { +\fBtestConstraint\fR X [expr $myRequirement] +\fBtest\fR goodConditionalTest {} X { # body } result .CE @@ -967,23 +967,23 @@ should be called. Here is a sketch of a sample test file illustrating those points: .CS package require tcltest 2.2 -eval tcltest::configure $argv +eval \fB::tcltest::configure\fR $argv package require example namespace eval ::example::test { namespace import ::tcltest::* - testConstraint X [expr {...}] + \fBtestConstraint\fR X [expr {...}] variable SETUP {#common setup code} variable CLEANUP {#common cleanup code} - test example-1 {} -setup $SETUP -body { + \fBtest\fR example-1 {} -setup $SETUP -body { # First test } -cleanup $CLEANUP -result {...} - test example-2 {} -constraints X -setup $SETUP -body { + \fBtest\fR example-2 {} -constraints X -setup $SETUP -body { # Second test; constrained } -cleanup $CLEANUP -result {...} - test example-3 {} { + \fBtest\fR example-3 {} { # Third test; no context required } {...} - cleanupTests + \fBcleanupTests\fR } namespace delete ::example::test .CE @@ -1000,10 +1000,10 @@ Here is a sketch of a sample test suite master script: package require Tcl 8.4 package require tcltest 2.2 package require example -tcltest::configure -testdir \ +\fB::tcltest::configure\fR -testdir \ [file dirname [file normalize [info script]]] -eval tcltest::configure $argv -tcltest::runAllTests +eval \fB::tcltest::configure\fR $argv +\fB::tcltest::runAllTests\fR .CE .SH COMPATIBILITY .PP @@ -1021,7 +1021,7 @@ 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 +eval \fB::tcltest::configure\fR $::argv .CE to establish a configuration from command line arguments. .SH "KNOWN ISSUES" @@ -1030,9 +1030,9 @@ 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} { +\fBtest\fR level-1.1 {level 1} { -body { - test level-2.1 {level 2} { + \fBtest\fR level-2.1 {level 2} { } } } |