Manual Pages for UNIX Darwin command on man tcltest

tcltest(n) Tcl Bundled Packages tcltest(n)

NAME

tcltest - Test harness support code and utilities

SYNOPSIS

ppaacckkaaggee rreeqquuiirree ttcclltteesstt ??22..22..55?? ttcclltteesstt::::tteesstt name description ?option value ...? ttcclltteesstt::::tteesstt name description ?constraints? body result ttcclltteesstt::::llooaaddTTeesstteeddCCoommmmaannddss ttcclltteesstt::::mmaakkeeDDiirreeccttoorryy name ?directory? ttcclltteesstt::::rreemmoovveeDDiirreeccttoorryy name ?directory? ttcclltteesstt::::mmaakkeeFFiillee contents name ?directory? ttcclltteesstt::::rreemmoovveeFFiillee name ?directory? ttcclltteesstt::::vviieewwFFiillee name ?directory? ttcclltteesstt::::cclleeaannuuppTTeessttss ?runningMultipleTests? ttcclltteesstt::::rruunnAAllllTTeessttss ttcclltteesstt::::ccoonnffiigguurree ttcclltteesstt::::ccoonnffiigguurree option ttcclltteesstt::::ccoonnffiigguurree option value ?option value ...? ttcclltteesstt::::ccuussttoommMMaattcchh mode command ttcclltteesstt::::tteessttCCoonnssttrraaiinntt constraint ?value? ttcclltteesstt::::oouuttppuuttCChhaannnneell ?channelID? ttcclltteesstt::::eerrrroorrCChhaannnneell ?channelID? ttcclltteesstt::::iinntteerrpprreetteerr ?interp? ttcclltteesstt::::ddeebbuugg ?level? ttcclltteesstt::::eerrrroorrFFiillee ?filename? ttcclltteesstt::::lliimmiittCCoonnssttrraaiinnttss ?boolean? ttcclltteesstt::::llooaaddFFiillee ?filename? ttcclltteesstt::::llooaaddSSccrriipptt ?script? ttcclltteesstt::::mmaattcchh ?patternList? ttcclltteesstt::::mmaattcchhDDiirreeccttoorriieess ?patternList? ttcclltteesstt::::mmaattcchhFFiilleess ?patternList? ttcclltteesstt::::oouuttppuuttFFiillee ?filename? ttcclltteesstt::::pprreesseerrvveeCCoorree ?level? ttcclltteesstt::::ssiinngglleePPrroocceessss ?boolean? ttcclltteesstt::::sskkiipp ?patternList? ttcclltteesstt::::sskkiippDDiirreeccttoorriieess ?patternList? ttcclltteesstt::::sskkiippFFiilleess ?patternList? ttcclltteesstt::::tteemmppoorraarryyDDiirreeccttoorryy ?directory? ttcclltteesstt::::tteessttssDDiirreeccttoorryy ?directory? ttcclltteesstt::::vveerrbboossee ?level? ttcclltteesstt::::tteesstt name description optionList ttcclltteesstt::::bbyytteessttrriinngg string ttcclltteesstt::::nnoorrmmaalliizzeeMMssgg msg ttcclltteesstt::::nnoorrmmaalliizzeePPaatthh pathVar ttcclltteesstt::::wwoorrkkiinnggDDiirreeccttoorryy ?dir?

DESCRIPTION

The ttcclltteesstt package provides several utility commands useful in the

construction of test suites for code instrumented to be run by evalua-

tion of Tcl commands. Notably the built-in commands of the Tcl library

itself are tested by a test suite using the tcltest package.

All the commands provided by the ttcclltteesstt package are defined in and

xotd rm h ::tcltest nmsae a idctd n h SYNOPSIS

above. In the following sections, all commands will be described by their simple names, in the interest of brevity. The central command of ttcclltteesstt is [tteesstt] that defines and runs a test. Testing with [tteesstt] involves evaluation of a Tcl script and comparing the result to an expected result, as configured and controlled by a number of options. Several other commands provided by ttcclltteesstt govern the configuration of [tteesstt] and the collection of many [tteesstt] commands into test suites. See CCRREEAATTIINNGG TTEESSTT SSUUIITTEESS WWIITTHH TTCCLLTTEESSTT below for an extended example of

how to use the commands of ttcclltteesstt to produce test suites for your Tcl-

enabled code. CCOOMMMMAANNDDSS tteesstt name description ?option value ...?

Defines and possibly runs a test with the name name and descrip-

tion description. The name and description of a test are used in messages reported by [tteesstt] during the test, as configured by the options of ttcclltteesstt. The remaining option value arguments to

[tteesstt] define the test, including the scripts to run, the condi-

tions under which to run them, the expected result, and the

means by which the expected and actual results should be com-

pared. See TTEESSTTSS below for a complete description of the valid options and how they define a test. The [tteesstt] command returns an empty string. tteesstt name description ?constraints? body result This form of [tteesstt] is provided to support test suites written

for version 1 of the ttcclltteesstt package, and also a simpler inter-

face for a common usage. It is the same as [tteesstt name descrip-

tion -ccoonnssttrraaiinnttss constraints -bbooddyy body -rreessuulltt result]. All

other options to [tteesstt] take their default values. When con-

straints is omitted, this form of [tteesstt] can be distinguished

from the first because all options begin with ``-''.

llooaaddTTeesstteeddCCoommmmaannddss

Evaluates in the caller's context the script specified by [ccoonn-

ffiigguurree -llooaadd] or [ccoonnffiigguurree -llooaaddffiillee]. Returns the result of

that script evaluation, including any error raised by the script. Use this command and the related configuration options to provide the commands to be tested to the interpreter running the test suite. mmaakkeeFFiillee contents name ?directory? Creates a file named name relative to directory directory and

write contents to that file using the encoding [eennccooddiinngg ssyyss-

tteemm]. If contents does not end with a newline, a newline will be appended so that the file named name does end with a newline.

Because the system encoding is used, this command is only suit-

able for making text files. The file will be removed by the next evaluation of [cclleeaannuuppTTeessttss], unless it is removed by [rreemmoovveeFFiillee] first. The default value of directory is the

directory [ccoonnffiigguurree -ttmmppddiirr]. Returns the full path of the

file created. Use this command to create any text file required by a test with contents as needed. rreemmoovveeFFiillee name ?directory? Forces the file referenced by name to be removed. This file name should be relative to directory. The default value of

directory is the directory [ccoonnffiigguurree -ttmmppddiirr]. Returns an

empty string. Use this command to delete files created by [mmaakkeeFFiillee]. mmaakkeeDDiirreeccttoorryy name ?directory? Creates a directory named name relative to directory directory. The directory will be removed by the next evaluation of [cclleeaannuuppTTeessttss], unless it is removed by [rreemmoovveeDDiirreeccttoorryy] first. The default value of directory is the directory [ccoonnffiigguurree

-ttmmppddiirr]. Returns the full path of the directory created. Use

this command to create any directories that are required to exist by a test. rreemmoovveeDDiirreeccttoorryy name ?directory? Forces the directory referenced by name to be removed. This directory should be relative to directory. The default value of

directory is the directory [ccoonnffiigguurree -ttmmppddiirr]. Returns an

empty string. Use this command to delete any directories cre-

ated by [mmaakkeeDDiirreeccttoorryy]. vviieewwFFiillee file ?directory? Returns the contents of file, except for any final newline, just

as [rreeaadd -nnoonneewwlliinnee] would return. This file name should be

relative to directory. The default value of directory is the

directory [ccoonnffiigguurree -ttmmppddiirr]. Use this command as a convenient

way to turn the contents of a file generated by a test into the result of that test for matching against an expected result. The contents of the file are read using the system encoding, so its usefulness is limited to text files. cclleeaannuuppTTeessttss Intended to clean up and summarize after several tests have been run. Typically called once per test file, at the end of the

file after all tests have been completed. For best effective-

ness, be sure that the [cclleeaannuuppTTeessttss] is evaluated even if an error occurs earlier in the test file evaluation. Prints statistics about the tests run and removes files that were created by [mmaakkeeDDiirreeccttoorryy] and [mmaakkeeFFiillee] since the last [cclleeaannuuppTTeessttss]. Names of files and directories in the directory

[ccoonnffiigguurree -ttmmppddiirr] created since the last [cclleeaannuuppTTeessttss], but

not created by [mmaakkeeFFiillee] or [mmaakkeeDDiirreeccttoorryy] are printed to [oouuttppuuttCChhaannnneell]. This command also restores the original shell environment, as described by the ::env array. Returns an empty string. rruunnAAllllTTeessttss This is a master command meant to run an entire suite of tests, spanning multiple files and/or directories, as governed by the configurable options of ttcclltteesstt. See RRUUNNNNIINNGG AALLLL TTEESSTTSS below for a complete description of the many variations possible with [rruunnAAllllTTeessttss]. CCOONNFFIIGGUURRAATTIIOONN CCOOMMMMAANNDDSS ccoonnffiigguurree Returns the list of configurable options supported by ttcclltteesstt. See CCOONNFFIIGGUURRAABBLLEE OOPPTTIIOONNSS below for the full list of options, their valid values, and their effect on ttcclltteesstt operations. ccoonnffiigguurree option Returns the current value of the supported configurable option

option. Raises an error if option is not a supported config-

urable option. ccoonnffiigguurree option value ?option value ...?

Sets the value of each configurable option option to the corre-

sponding value value, in order. Raises an error if an option is not a supported configurable option, or if value is not a valid

value for the corresponding option, or if a value is not pro-

vided. When an error is raised, the operation of [ccoonnffiigguurree] is halted, and subsequent option value arguments are not processed. If the environment variable ::::eennvv((TTCCLLTTEESSTTOOPPTTIIOONNSS)) exists when the ttcclltteesstt package is loaded (by [ppaacckkaaggee rreeqquuiirree ttcclltteesstt])

then its value is taken as a list of arguments to pass to [ccoonn-

ffiigguurree]. This allows the default values of the configuration options to be set by the environment. ccuussttoommMMaattcchh mode script

Registers mode as a new legal value of the -mmaattcchh option to

[tteesstt]. When the -mmaattcchh mode option is passed to [tteesstt], the

script script will be evaluated to compare the actual result of

evaluating the body of the test to the expected result. To per-

form the match, the script is completed with two additional

words, the expected result, and the actual result, and the com-

pleted script is evaluated in the global namespace. The com-

pleted script is expected to return a boolean value indicating

whether or not the results match. The built-in matching modes

of [tteesstt] are eexxaacctt, gglloobb, and rreeggeexxpp. tteessttCCoonnssttrraaiinntt constraint ?boolean?

Sets or returns the boolean value associated with the named con-

straint. See TTEESSTT CCOONNSSTTRRAAIINNTTSS below for more information. iinntteerrpprreetteerr ?executableName? Sets or returns the name of the executable to be [eexxeecc]ed by

[rruunnAAllllTTeessttss] to run each test file when [ccoonnffiigguurree -ssiinngglleepprroocc]

is false. The default value for [iinntteerrpprreetteerr] is the name of

the currently running program as returned by [iinnffoo nnaammeeooffeexxee-

ccuuttaabbllee]. oouuttppuuttCChhaannnneell ?channelID? Sets or returns the output channel ID. This defaults to stdout. Any test that prints test related output should send that output to [oouuttppuuttCChhaannnneell] rather than letting that output default to stdout. eerrrroorrCChhaannnneell ?channelID? Sets or returns the error channel ID. This defaults to stderr. Any test that prints error messages should send that output to [eerrrroorrCChhaannnneell] rather than printing directly to stderr. SSHHOORRTTCCUUTT CCOOMMMMAANNDDSS ddeebbuugg ?level?

Same as [ccoonnffiigguurree -ddeebbuugg ?level?].

eerrrroorrFFiillee ?filename?

Same as [ccoonnffiigguurree -eerrrrffiillee ?filename?].

lliimmiittCCoonnssttrraaiinnttss ?boolean?

Same as [ccoonnffiigguurree -lliimmiittccoonnssttrraaiinnttss ?boolean?].

llooaaddFFiillee ?filename?

Same as [ccoonnffiigguurree -llooaaddffiillee ?filename?].

llooaaddSSccrriipptt ?script?

Same as [ccoonnffiigguurree -llooaadd ?script?].

mmaattcchh ?patternList?

Same as [ccoonnffiigguurree -mmaattcchh ?patternList?].

mmaattcchhDDiirreeccttoorriieess ?patternList?

Same as [ccoonnffiigguurree -rreellaatteeddddiirr ?patternList?].

mmaattcchhFFiilleess ?patternList?

Same as [ccoonnffiigguurree -ffiillee ?patternList?].

oouuttppuuttFFiillee ?filename?

Same as [ccoonnffiigguurree -oouuttffiillee ?filename?].

pprreesseerrvveeCCoorree ?level?

Same as [ccoonnffiigguurree -pprreesseerrvveeccoorree ?level?].

ssiinngglleePPrroocceessss ?boolean?

Same as [ccoonnffiigguurree -ssiinngglleepprroocc ?boolean?].

sskkiipp ?patternList?

Same as [ccoonnffiigguurree -sskkiipp ?patternList?].

sskkiippDDiirreeccttoorriieess ?patternList?

Same as [ccoonnffiigguurree -aassiiddeeffrroommddiirr ?patternList?].

sskkiippFFiilleess ?patternList?

Same as [ccoonnffiigguurree -nnoottffiillee ?patternList?].

tteemmppoorraarryyDDiirreeccttoorryy ?directory?

Same as [ccoonnffiigguurree -ttmmppddiirr ?directory?].

tteessttssDDiirreeccttoorryy ?directory?

Same as [ccoonnffiigguurree -tteessttddiirr ?directory?].

vveerrbboossee ?level?

Same as [ccoonnffiigguurree -vveerrbboossee ?level?].

OOTTHHEERR CCOOMMMMAANNDDSS The remaining commands provided by ttcclltteesstt have better alternatives

provided by ttcclltteesstt or TTccll itself. They are retained to support exist-

ing test suites, but should be avoided in new code. tteesstt name description optionList This form of [tteesstt] was provided to enable passing many options spanning several lines to [tteesstt] as a single argument quoted by braces, rather than needing to backslash quote the newlines between arguments to [tteesstt]. The optionList argument is

expected to be a list with an even number of elements represent-

ing option and value arguments to pass to [tteesstt]. However, these values are not passed directly, as in the alternate forms of [sswwiittcchh]. Instead, this form makes an unfortunate attempt to overthrow Tcl's substitution rules by performing substitutions on some of the list elements as an attempt to implement a ``do

what I mean'' interpretation of a brace-enclosed ``block''. The

result is nearly impossible to document clearly, and for that

reason this form is not recommended. See the examples in CCRREEAATT-

IINNGG TTEESSTT SSUUIITTEESS WWIITTHH TTCCLLTTEESSTT below to see that this form is

really not necessary to avoid backslash-quoted newlines. If you

insist on using this form, examine the source code of ttcclltteesstt if you want to know the substitution details, or just enclose the third through last argument to [tteesstt] in braces and hope for the best. wwoorrkkiinnggDDiirreeccttoorryy ?directoryName? Sets or returns the current working directory when the test suite is running. The default value for workingDirectory is the

directory in which the test suite was launched. The Tcl com-

mands [ccdd] and [ppwwdd] are sufficient replacements. nnoorrmmaalliizzeeMMssgg msg Returns the result of removing the ``extra'' newlines from msg, where ``extra'' is rather imprecise. Tcl offers plenty of string processing commands to modify strings as you wish, and [ccuussttoommMMaattcchh] allows flexible matching of actual and expected results. nnoorrmmaalliizzeePPaatthh pathVar

Resolves symlinks in a path, thus creating a path without inter-

nal redirection. It is assumed that pathVar is absolute. path-

Var is modified in place. The Tcl command [ffiillee nnoorrmmaalliizzee] is a sufficient replacement. bbyytteessttrriinngg string Construct a string that consists of the requested sequence of

bytes, as opposed to a string of properly formed UTF-8 charac-

ters using the value supplied in string. This allows the tester to create denormalized or improperly formed strings to pass to C procedures that are supposed to accept strings with embedded

NULL types and confirm that a string result has a certain pat-

tern of bytes. This is exactly equivalent to the Tcl command [eennccooddiinngg ccoonnvveerrttffrroomm iiddeennttiittyy]. TTEESSTTSS The [tteesstt] command is the heart of the ttcclltteesstt package. Its essential function is to evaluate a Tcl script and compare the result with an expected result. The options of [tteesstt] define the test script, the environment in which to evaluate it, the expected result, and how the compare the actual result to the expected result. Some configuration options of ttcclltteesstt also influence how [tteesstt] operates. The valid options for [tteesstt] are summarized: test name description

?-constraints keywordList|expression?

?-setup setupScript?

?-body testScript?

?-cleanup cleanupScript?

?-result expectedAnswer?

?-output expectedOutput?

?-errorOutput expectedError?

?-returnCodes codeList?

?-match mode?

The name may be any string. It is conventional to choose a name according to the pattern:

target-majorNum.minorNum

For white-box (regression) tests, the target should be the name of the

C function or Tcl procedure being tested. For black-box tests, the

target should be the name of the feature being tested. Some conven-

tions call for the names of black-box tests to have the suffix bbbb.

Related tests should share a major number. As a test suite evolves, it is best to have the same test name continue to correspond to the same

test, so that it remains meaningful to say things like ``Test foo-1.3

passed in all releases up to 3.4, but began failing in release 3.5.'' During evaluation of [tteesstt], the name will be compared to the lists of

string matching patterns returned by [ccoonnffiigguurree -mmaattcchh], and [ccoonnffiigguurree

-sskkiipp]. The test will be run only if name matches any of the patterns

from [ccoonnffiigguurree -mmaattcchh] and matches none of the patterns from [ccoonnffiigg-

uurree -sskkiipp].

The description should be a short textual description of the test. The description is included in output produced by the test, typically test failure messages. Good description values should briefly explain the purpose of the test to users of a test suite. The name of a Tcl or C

function being tested should be included in the description for regres-

sion tests. If the test case exists to reproduce a bug, include the bug ID in the description. Valid attributes and associated values are:

-ccoonnssttrraaiinnttss keywordList|expression

The optional -ccoonnssttrraaiinnttss attribute can be list of one or more

keywords or an expression. If the -ccoonnssttrraaiinnttss value is a list

of keywords, each of these keywords should be the name of a con-

straint defined by a call to [tteessttCCoonnssttrraaiinntt]. If any of the listed constraints is false or does not exist, the test is

skipped. If the -ccoonnssttrraaiinnttss value is an expression, that

expression is evaluated. If the expression evaluates to true,

then the test is run. Note that the expression form of -ccoonn-

ssttrraaiinnttss may interfere with the operation of [ccoonnffiigguurree -ccoonn-

ssttrraaiinnttss] and [ccoonnffiigguurree -lliimmiittccoonnssttrraaiinnttss], and is not recom-

mended. Appropriate constraints should be added to any tests that should not always be run. That is, conditional evaluation

of a test should be accomplished by the -ccoonnssttrraaiinnttss option, not

by conditional evaluation of [tteesstt]. In that way, the same num-

ber of tests are always reported by the test suite, though the number skipped may change based on the testing environment. The default value is an empty list. See TTEESSTT CCOONNSSTTRRAAIINNTTSS below for

a list of built-in constraints and information on how to add

your own constraints.

-sseettuupp script

The optional -sseettuupp attribute indicates a script that will be

run before the script indicated by the -bbooddyy attribute. If

evaluation of script raises an error, the test will fail. The default value is an empty script.

-bbooddyy script

The -bbooddyy attribute indicates the script to run to carry out the

test. It must return a result that can be checked for correct-

ness. If evaluation of script raises an error, the test will fail. The default value is an empty script.

-cclleeaannuupp script

The optional -cclleeaannuupp attribute indicates a script that will be

run after the script indicated by the -bbooddyy attribute. If eval-

uation of script raises an error, the test will fail. The default value is an empty script.

-mmaattcchh mode

The -mmaattcchh attribute determines how expected answers supplied by

-rreessuulltt, -oouuttppuutt, and -eerrrroorrOOuuttppuutt are compared. Valid values

for mode are rreeggeexxpp, gglloobb, eexxaacctt, and any value registered by a prior call to [ccuussttoommMMaattcchh]. The default value is eexxaacctt.

-rreessuulltt expectedValue

The -rreessuulltt attribute supplies the expectedValue against which

the return value from script will be compared. The default value is an empty string.

-oouuttppuutt expectedValue

The -oouuttppuutt attribute supplies the expectedValue against which

any output sent to ssttddoouutt or [oouuttppuuttCChhaannnneell] during evaluation of the script(s) will be compared. Note that only output

printed using [::::ppuuttss] is used for comparison. If -oouuttppuutt is

not specified, output sent to ssttddoouutt and [oouuttppuuttCChhaannnneell] is not processed for comparison.

-eerrrroorrOOuuttppuutt expectedValue

The -eerrrroorrOOuuttppuutt attribute supplies the expectedValue against

which any output sent to ssttddeerrrr or [eerrrroorrCChhaannnneell] during evalua-

tion of the script(s) will be compared. Note that only output

printed using [::::ppuuttss] is used for comparison. If -eerrrroorrOOuuttppuutt

is not specified, output sent to ssttddeerrrr and [eerrrroorrCChhaannnneell] is not processed for comparison.

-rreettuurrnnCCooddeess expectedCodeList

The optional -rreettuurrnnCCooddeess attribute supplies expectedCodeList, a

list of return codes that may be accepted from evaluation of the

-bbooddyy script. If evaluation of the -bbooddyy script returns a code

not in the expectedCodeList, the test fails. All return codes known to [rreettuurrnn], in both numeric and symbolic form, including

extended return codes, are acceptable elements in the expected-

CodeList. Default value is {{ookk rreettuurrnn}}.

To pass, a test must successfully evaluate its -sseettuupp, -bbooddyy, and

-cclleeaannuupp scripts. The return code of the -bbooddyy script and its result

must match expected values, and if specified, output and error data

from the test must match expected -oouuttppuutt and -eerrrroorrOOuuttppuutt values. If

any of these conditions are not met, then the test fails. Note that all scripts are evaluated in the context of the caller of [tteesstt]. As long as [tteesstt] is called with valid syntax and legal values for all attributes, it will not raise an error. Test failures are instead reported as output written to [oouuttppuuttCChhaannnneell]. In default operation, a successful test produces no output. The output messages produced by

[tteesstt] are controlled by the [ccoonnffiigguurree -vveerrbboossee] option as described

in CCOONNFFIIGGUURRAABBLLEE OOPPTTIIOONNSS below. Any output produced by the test scripts themselves should be produced using [::::ppuuttss] to [oouuttppuuttCChhaannnneell] or

[eerrrroorrCChhaannnneell], so that users of the test suite may easily capture out-

put with the [ccoonnffiigguurree -oouuttffiillee] and [ccoonnffiigguurree -eerrrrffiillee] options, and

so that the -oouuttppuutt and -eerrrroorrOOuuttppuutt attributes work properly.

TTEESSTT CCOONNSSTTRRAAIINNTTSS Constraints are used to determine whether or not a test should be skipped. Each constraint has a name, which may be any string, and a

boolean value. Each [tteesstt] has a -ccoonnssttrraaiinnttss value which is a list of

constraint names. There are two modes of constraint control. Most

frequently, the default mode is used, indicated by a setting of [ccoonn-

ffiigguurree -lliimmiittccoonnssttrraaiinnttss] to false. The test will run only if all con-

straints in the list are true-valued. Thus, the -ccoonnssttrraaiinnttss option of

[tteesstt] is a convenient, symbolic way to define any conditions required for the test to be possible or meaningful. For example, a [tteesstt] with

-ccoonnssttrraaiinnttss uunniixx will only be run if the constraint uunniixx is true,

which indicates the test suite is being run on a Unix platform.

Each [tteesstt] should include whatever -ccoonnssttrraaiinnttss are required to con-

strain it to run only where appropriate. Several constraints are pre-

defined in the ttcclltteesstt package, listed below. The registration of

user-defined constraints is performed by the [tteessttCCoonnssttrraaiinntt] command.

User-defined constraints may appear within a test file, or within the

script specified by the [ccoonnffiigguurree -llooaadd] or [ccoonnffiigguurree -llooaaddffiillee]

options.

The following is a list of constraints pre-defined by the ttcclltteesstt pack-

age itself: singleTestInterp test can only be run if all test files are sourced into a single interpreter unix test can only be run on any Unix platform win test can only be run on any Windows platform nt test can only be run on any Windows NT platform 95 test can only be run on any Windows 95 platform 98 test can only be run on any Windows 98 platform mac test can only be run on any Mac platform unixOrWin test can only be run on a Unix or Windows platform macOrWin test can only be run on a Mac or Windows platform macOrUnix test can only be run on a Mac or Unix platform tempNotWin

test can not be run on Windows. This flag is used to temporar-

ily disable a test. tempNotMac test can not be run on a Mac. This flag is used to temporarily disable a test. unixCrash

test crashes if it's run on Unix. This flag is used to tempo-

rarily disable a test. winCrash

test crashes if it's run on Windows. This flag is used to tem-

porarily disable a test. macCrash

test crashes if it's run on a Mac. This flag is used to tempo-

rarily disable a test. emptyTest test is empty, and so not worth running, but it remains as a

place-holder for a test to be written in the future. This con-

straint has value false to cause tests to be skipped unless the user specifies otherwise. knownBug

test is known to fail and the bug is not yet fixed. This con-

straint has value false to cause tests to be skipped unless the user specifies otherwise. nonPortable test can only be run in some known development environment.

Some tests are inherently non-portable because they depend on

things like word length, file system configuration, window man-

ager, etc. This constraint has value false to cause tests to be skipped unless the user specifies otherwise. userInteraction test requires interaction from the user. This constraint has

value false to causes tests to be skipped unless the user speci-

fies otherwise. interactive test can only be run in if the interpreter is in interactive mode (when the global tclinteractive variable is set to 1). nonBlockFiles test can only be run if platform supports setting files into nonblocking mode asyncPipeClose test can only be run if platform supports async flush and async close on a pipe unixExecs

test can only be run if this machine has Unix-style commands

ccaatt, eecchhoo, sshh, wwcc, rrmm, sslleeeepp, ffggrreepp, ppss, cchhmmoodd, and mmkkddiirr avail-

able hasIsoLocale test can only be run if can switch to an ISO locale root test can only run if Unix user is root notRoot test can only run if Unix user is not root eformat test can only run if app has a working version of sprintf with

respect to the "e" format of floating-point numbers.

stdio test can only be run if [iinntteerrpprreetteerr] can be [ooppeenn]ed as a pipe.

The alternative mode of constraint control is enabled by setting [ccoonn-

ffiigguurree -lliimmiittccoonnssttrraaiinnttss] to true. With that configuration setting,

all existing constraints other than those in the constraint list

returned by [ccoonnffiigguurree -ccoonnssttrraaiinnttss] are set to false. When the value

of [ccoonnffiigguurree -ccoonnssttrraaiinnttss] is set, all those constraints are set to

true. The effect is that when both options [ccoonnffiigguurree -ccoonnssttrraaiinnttss]

and [ccoonnffiigguurree -lliimmiittccoonnssttrraaiinnttss] are in use, only those tests includ-

ing only constraints from the [ccoonnffiigguurree -ccoonnssttrraaiinnttss] list are run;

all others are skipped. For example, one might set up a configuration with

configure -constraints knownBug \

-limitconstraints true \

-verbose pass

to run exactly those tests that exercise known bugs, and discover whether any of them pass, indicating the bug had been fixed. RRUUNNNNIINNGG AALLLL TTEESSTTSS The single command [rruunnAAllllTTeessttss] is evaluated to run an entire test suite, spanning many files and directories. The configuration options of ttcclltteesstt control the precise operations. The [rruunnAAllllTTeessttss] command begins by printing a summary of its configuration to [oouuttppuuttCChhaannnneell]. Test files to be evaluated are sought in the directory [ccoonnffiigguurree

-tteessttddiirr]. The list of files in that directory that match any of the

patterns in [ccoonnffiigguurree -ffiillee] and match none of the patterns in [ccoonn-

ffiigguurree -nnoottffiillee] is generated and sorted. Then each file will be eval-

uated in turn. If [ccoonnffiigguurree -ssiinngglleepprroocc] is true, then each file will

be [ssoouurrccee]d in the caller's context. If if is false, then a copy of

[iinntteerrpprreetteerr] will be [eexxeecc]d to evaluate each file. The multi-process

operation is useful when testing can cause errors so severe that a process terminates. Although such an error may terminate a child process evaluating one file, the master process can continue with the

rest of the test suite. In multi-process operation, the configuration

of ttcclltteesstt in the master process is passed to the child processes as

command line arguments, with the exception of [ccoonnffiigguurree -oouuttffiillee].

The [rruunnAAllllTTeessttss] command in the master process collects all output from the child processes and collates their results into one master report. Any reports of individual test failures, or messages requested

by a [ccoonnffiigguurree -vveerrbboossee] setting are passed directly on to [oouutt-

ppuuttCChhaannnneell] by the master process. After evaluating all selected test files, a summary of the results is printed to [oouuttppuuttCChhaannnneell]. The summary includes the total number of [tteesstt]s evaluated, broken down into those skipped, those passed, and those failed. The summary also notes the number of files evaluated, and the names of any files with failing tests or errors. A list of 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 [ccoonnffiigguurree -ttmmppddiirr].

Having completed and summarized all selected test files, [rruunnAAllllTTeessttss]

then recursively acts on subdirectories of [ccoonnffiigguurree -tteessttddiirr]. All

subdirectories that match any of the patterns in [ccoonnffiigguurree -rreellaatteedd-

ddiirr] and do not match any of the patterns in [ccoonnffiigguurree -aassiiddeeffrroommddiirr]

are examined. If a file named aallll..ttccll is found in such a directory, it will be [ssoouurrccee]d in the caller's context. Whether or not an examined directory contains an aallll..ttccll file, its subdirectories are also scanned

against the [ccoonnffiigguurree -rreellaatteeddddiirr] and [ccoonnffiigguurree -aassiiddeeffrroommddiirr] pat-

terns. In this way, many directories in a directory tree can have all their test files evaluated by a single [rruunnAAllllTTeessttss] command. CCOONNFFIIGGUURRAABBLLEE OOPPTTIIOONNSS The [ccoonnffiigguurree] command is used to set and query the configurable options of ttcclltteesstt. The valid options are:

-ssiinngglleepprroocc boolean

Controls whether or not [rruunnAAllllTTeessttss] spawns a child process for each test file. No spawning when boolean is true. Default value is false.

-ddeebbuugg level

Sets the debug level to level, 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 [ccoonnffiigguurree -oouuttffiillee]. Default value is 0. Levels are

defined as: 0 Do not display any debug information. 1 Display information regarding whether a test is skipped

because it doesn't match any of the tests that were spec-

ified using by [ccoonnffiigguurree -mmaattcchh] (userSpecifiedNonMatch)

or matches any of the tests specified by [ccoonnffiigguurree

-sskkiipp] (userSpecifiedSkip). Also print warnings about

possible lack of cleanup or balance in test files. Also

print warnings about any re-use of test names.

2 Display the flag array parsed by the command line proces-

sor, the contents of the ::env array, and all user-

defined variables that exist in the current namespace as they are used. 3 Display information regarding what individual procs in the test harness are doing.

-vveerrbboossee level

Sets the type of output verbosity desired to level, a list of zero or more of the elements bbooddyy, ppaassss, sskkiipp, ssttaarrtt, and eerrrroorr. Default value is {{bbooddyy eerrrroorr}}. Levels are defined as: body (b) Display the body of failed tests pass (p) Print output when a test passes skip (s) Print output when a test is skipped start (t) Print output whenever a test starts error (e) Print errorInfo and errorCode, if they exist, when a test return code does not match its expected return code The single letter abbreviations noted above are also recognized so that

[ccoonnffiigguurree -vveerrbboossee pptt] is the same as [ccoonnffiigguurree -vveerrbboossee {{ppaassss

ssttaarrtt}}].

-pprreesseerrvveeccoorree level

Sets the core preservation level to level. This level deter-

mines how stringent checks for core files are. Default value is 0. Levels are defined as:

0 No checking - do not check for core files at the end of

each test command, but do check for them in [rruunnAAllllTTeessttss] after all test files have been evaluated.

1 Also check for core files at the end of each [tteesstt] com-

mand. 2 Check for core files at all times described above, and save a copy of each core file produced in [ccoonnffiigguurree

-ttmmppddiirr].

-lliimmiittccoonnssttrraaiinnttss boolean

Sets the mode by which [tteesstt] honors constraints as described in TTEESSTTSS above. Default value is false.

-ccoonnssttrraaiinnttss list

Sets all the constraints in list to true. Also used in combina-

tion with [ccoonnffiigguurree -lliimmiittccoonnssttrraaiinnttss ttrruuee] to control an

alternative constraint mode as described in TTEESSTTSS above. Default value is an empty list.

-ttmmppddiirr directory

Sets the temporary directory to be used by [mmaakkeeFFiillee], [mmaakkeeDDii-

rreeccttoorryy], [vviieewwFFiillee], [rreemmoovveeFFiillee], and [rreemmoovveeDDiirreeccttoorryy] as the default directory where temporary files and directories created

by test files should be created. Default value is [wwoorrkkiinnggDDii-

rreeccttoorryy].

-tteessttddiirr directory

Sets the directory searched by [rruunnAAllllTTeessttss] for test files and subdirectories. Default value is [wwoorrkkiinnggDDiirreeccttoorryy].

-ffiillee patternList

Sets the list of patterns used by [rruunnAAllllTTeessttss] to determine what test files to evaluate. Default value is **..tteesstt.

-nnoottffiillee patternList

Sets the list of patterns used by [rruunnAAllllTTeessttss] to determine what test files to skip. Default value is ll..**..tteesstt, so that any SCCS lock files are skipped.

-rreellaatteeddddiirr patternList

Sets the list of patterns used by [rruunnAAllllTTeessttss] to determine what subdirectories to search for an aallll..ttccll file. Default value is **.

-aassiiddeeffrroommddiirr patternList

Sets the list of patterns used by [rruunnAAllllTTeessttss] to determine what subdirectories to skip when searching for an aallll..ttccll file. Default value is an empty list.

-mmaattcchh patternList

Set the list of patterns used by [tteesstt] to determine whether a test should be run. Default value is **.

-sskkiipp patternList

Set the list of patterns used by [tteesstt] to determine whether a test should be skipped. Default value is an empty list.

-llooaadd script

Sets a script to be evaluated by [llooaaddTTeesstteeddCCoommmmaannddss]. Default value is an empty script.

-llooaaddffiillee filename

Sets the filename from which to read a script to be evaluated by

[llooaaddTTeesstteeddCCoommmmaannddss]. This is an alternative to -llooaadd. They

cannot be used together.

-oouuttffiillee filename

Sets the file to which all output produced by tcltest should be

written. A file named filename will be [ooppeenn]ed for writing,

and the resulting channel will be set as the value of [oouutt-

ppuuttCChhaannnneell].

-eerrrrffiillee filename

Sets the file to which all error output produced by tcltest

should be written. A file named filename will be [ooppeenn]ed for writing, and the resulting channel will be set as the value of [eerrrroorrCChhaannnneell]. CCRREEAATTIINNGG TTEESSTT SSUUIITTEESS WWIITTHH TTCCLLTTEESSTT

The fundamental element of a test suite is the individual [tteesstt] com-

mand. We begin with several examples. [1] Test of a script that returns normally.

test example-1.0 {normal return} {

format %s value

} value [2] Test of a script that requires context setup and cleanup. Note the bracing and indenting style that avoids any need for line continuation.

test example-1.1 {test file existence} -setup {

set file [makeFile {} test]

} -body {

file exists $file

} -cleanup {

removeFile test

} -result 1

[3] Test of a script that raises an error.

test example-1.2 {error return} -body {

error message

} -returnCodes error -result message

[4] Test with a constraint.

test example-1.3 {user owns created files} -constraints {

unix

} -setup {

set file [makeFile {} test]

} -body {

file attributes $file -owner

} -cleanup {

removeFile test

} -result $::tclplatform(user)

At the next higher layer of organization, several [tteesstt] commands are gathered together into a single test file. Test files should have names with the ..tteesstt extension, because that is the default pattern used by [rruunnAAllllTTeessttss] 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. Most of the code in the test file should be the [tteesstt] commands. Use constraints to skip tests, rather than conditional evaluation of [tteesstt]. That is, do this: [5]

testConstraint X [expr $myRequirement]

test goodConditionalTest {} X {

# body

} result and do not do this: [6]

if $myRequirement {

test badConditionalTest {} {

#body

} result }

Use the -sseettuupp and -cclleeaannuupp options to establish and release all con-

text 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

-sseettuupp and -cclleeaannuupp options. This is a better solution than performing

setup outside of [tteesstt] 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. A test file should be able to be combined with other test files and not

interfere with them, even when [ccoonnffiigguurree -ssiinngglleepprroocc 11] 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 tteesstt of the namespace of the module you are testing. A test file should also be able to be evaluated directly as a script, not depending on being called by a master [rruunnAAllllTTeessttss]. This means that each test file should process command line arguments to give the tester all the configuration control that ttcclltteesstt provides. After all [tteesstt]s in a test file, the command [cclleeaannuuppTTeessttss] should be called. [7] Here is a sketch of a sample test file illustrating those points:

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 -body {

# First test

} -cleanup $CLEANUP -result {...}

test example-2 {} -constraints X -setup $SETUP -body {

# Second test; constrained

} -cleanup $CLEANUP -result {...}

test example-3 {} {

# Third test; no context required

} {...} cleanupTests } namespace delete ::example::test 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 [rruunnAAllllTTeessttss] after doing any neces-

sary setup. This script is usually named aallll..ttccll because that's the default name used by [rruunnAAllllTTeessttss] when combining multiple test suites into one testing run. [8] 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 [file dirname [file normalize [info script]]]

eval tcltest::configure $argv

tcltest::runAllTests

CCOOMMPPAATTIIBBIILLIITTYY A number of commands and variables in the ::::ttcclltteesstt namespace provided by earlier releases of ttcclltteesstt have not been documented here. They are no longer part of the supported public interface of ttcclltteesstt and should

not be used in new test suites. However, to continue to support exist-

ing test suites written to the older interface specifications, many of those deprecated commands and variables still work as before. For example, in many circumstances, [ccoonnffiigguurree] will be automatically

called shortly after [ppaacckkaaggee rreeqquuiirree ttcclltteesstt 22..11] succeeds with argu-

ments from the variable ::::aarrggvv. This is to support test suites that depend on the old behavior that ttcclltteesstt was automatically configured from command line arguments. New test files should not depend on this, but should explicitly include

eval tcltest::configure $::argv

to establish a configuration from command line arguments. KKNNOOWWNN IISSSSUUEESS There are two known issues related to nested evaluations of [tteesstt]. 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:

test level-1.1 {level 1} {

-body {

test level-2.1 {level 2} {

} } }

any script executed in level-2.1 may be executed at the same stack

level as the script defined for level-1.1.

In addition, while two [tteesstt]s have been run, results will only be reported by [cclleeaannuuppTTeessttss] 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.

Implementation of output and error comparison in the test command

depends on usage of ::puts in your application code. Output is inter-

cepted 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 -oouuttppuutt and -eerrrroorrOOuuppuutt options to [tteesstt] is useful only for

pure Tcl applications that use [::::ppuuttss] to produce output. KKEEYYWWOORRDDSS test, test harness, test suite