NAME

tcltest - Test harness support code and utilities

SYNOPSIS

package require tcltest ?2.5?
tcltest::test name description ?-option value ...?
tcltest::test name description ?constraints? body result
tcltest::loadTestedCommands
tcltest::makeDirectory name ?directory?
tcltest::removeDirectory name ?directory?
tcltest::makeFile contents name ?directory?
tcltest::removeFile name ?directory?
tcltest::viewFile name ?directory?
tcltest::cleanupTests ?runningMultipleTests?
tcltest::runAllTests
tcltest::configure
tcltest::configure -option
tcltest::configure -option value ?-option value ...?
tcltest::customMatch mode command
tcltest::testConstraint constraint ?value?
tcltest::outputChannel ?channelID?
tcltest::errorChannel ?channelID?
tcltest::interpreter ?interp?
tcltest::debug ?level?
tcltest::errorFile ?filename?
tcltest::limitConstraints ?boolean?
tcltest::loadFile ?filename?
tcltest::loadScript ?script?
tcltest::match ?patternList?
tcltest::matchDirectories ?patternList?
tcltest::matchFiles ?patternList?
tcltest::outputFile ?filename?
tcltest::preserveCore ?level?
tcltest::singleProcess ?boolean?
tcltest::skip ?patternList?
tcltest::skipDirectories ?patternList?
tcltest::skipFiles ?patternList?
tcltest::temporaryDirectory ?directory?
tcltest::testsDirectory ?directory?
tcltest::verbose ?level?
tcltest::test name description optionList
tcltest::bytestring string
tcltest::normalizeMsg msg
tcltest::normalizePath pathVar
tcltest::workingDirectory ?dir?

DESCRIPTION

The tcltest package provides several utility commands useful in the construction of test suites for code instrumented to be run by evaluation 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 tcltest package are defined in and exported from the ::tcltest namespace, as indicated in the SYNOPSIS above. In the following sections, all commands will be described by their simple names, in the interest of brevity.

The central command of tcltest is test that defines and runs a test. Testing with test 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 tcltest govern the configuration of test and the collection of many test commands into test suites.

See CREATING TEST SUITES WITH TCLTEST below for an extended example of how to use the commands of tcltest to produce test suites for your Tcl-enabled code.

COMMANDS

test name description ?-option value ...?

Defines and possibly runs a test with the name name and description description. The name and description of a test are used in messages reported by test during the test, as configured by the options of tcltest. The remaining option value arguments to test define the test, including the scripts to run, the conditions under which to run them, the expected result, and the means by which the expected and actual results should be compared. See TESTS below for a complete description of the valid options and how they define a test. The test command returns an empty string.

test name description ?constraints? body result

This form of test is provided to support test suites written for version 1 of the tcltest package, and also a simpler interface for a common usage. It is the same as “test name description -constraints constraints -body body -result result”. All other options to test take their default values. When constraints is omitted, this form of test can be distinguished from the first because all options begin with “-”.

loadTestedCommands

Evaluates in the caller's context the script specified by configure -load or configure -loadfile. 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.

makeFile contents name ?directory?

Creates a file named name relative to directory directory and write contents to that file using the encoding encoding system. 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 suitable for making text files. The file will be removed by the next evaluation of cleanupTests, unless it is removed by removeFile first. The default value of directory is the directory configure -tmpdir. Returns the full path of the file created. Use this command to create any text file required by a test with contents as needed.

removeFile 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 configure -tmpdir. Returns an empty string. Use this command to delete files created by makeFile.

makeDirectory name ?directory?

Creates a directory named name relative to directory directory. The directory will be removed by the next evaluation of cleanupTests, unless it is removed by removeDirectory first. The default value of directory is the directory configure -tmpdir. Returns the full path of the directory created. Use this command to create any directories that are required to exist by a test.

removeDirectory 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 configure -tmpdir. Returns an empty string. Use this command to delete any directories created by makeDirectory.

viewFile file ?directory?

Returns the contents of file, except for any final newline, just as read -nonewline would return. This file name should be relative to directory. The default value of directory is the directory configure -tmpdir. 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.

cleanupTests

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 effectiveness, be sure that the cleanupTests is evaluated even if an error occurs earlier in the test file evaluation.

runAllTests

This is a main command meant to run an entire suite of tests, spanning multiple files and/or directories, as governed by the configurable options of tcltest. See RUNNING ALL TESTS below for a complete description of the many variations possible with runAllTests.

TESTS

The test command is the heart of the tcltest package. Its essential function is to evaluate a Tcl script and compare the result with an expected result. The options of test 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 tcltest also influence how test operates.

The valid options for test are summarized:

test name description


        ?-constraints keywordList|expression?


        ?-setup setupScript?


        ?-body testScript?


        ?-cleanup cleanupScript?


        ?-result expectedAnswer?


        ?-output expectedOutput?


        ?-errorOutput expectedError?


        ?-returnCodes codeList?


        ?-errorCode expectedErrorCode?


        ?-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 conventions call for the names of black-box tests to have the suffix _bb. 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 test, the name will be compared to the lists of string matching patterns returned by configure -match, and configure -skip. The test will be run only if name matches any of the patterns from configure -match and matches none of the patterns from configure -skip.

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 regression tests. If the test case exists to reproduce a bug, include the bug ID in the description.

Valid attributes and associated values are:

-constraints keywordList|expression

The optional -constraints attribute can be list of one or more keywords or an expression. If the -constraints value is a list of keywords, each of these keywords should be the name of a constraint defined by a call to testConstraint. If any of the listed constraints is false or does not exist, the test is skipped. If the -constraints 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 -constraints may interfere with the operation of configure -constraints and configure -limitconstraints, and is not recommended. 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 -constraints option, not by conditional evaluation of test. In that way, the same number 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 TEST CONSTRAINTS below for a list of built-in constraints and information on how to add your own constraints.

-setup script

The optional -setup attribute indicates a script that will be run before the script indicated by the -body attribute. If evaluation of script raises an error, the test will fail. The default value is an empty script.

-body script

The -body attribute indicates the script to run to carry out the test, which must return a result that can be checked for correctness. If evaluation of script raises an error, the test will fail (unless the -returnCodes option is used to state that an error is expected). The default value is an empty script.

-cleanup script

The optional -cleanup attribute indicates a script that will be run after the script indicated by the -body attribute. If evaluation of script raises an error, the test will fail. The default value is an empty script.

-match mode

The -match attribute determines how expected answers supplied by -result, -output, and -errorOutput are compared. Valid values for mode are regexp, glob, exact, and any value registered by a prior call to customMatch. The default value is exact.

-result expectedValue

The -result attribute supplies the expectedValue against which the return value from script will be compared. The default value is an empty string.

-output expectedValue

The -output attribute supplies the expectedValue against which any output sent to stdout or outputChannel during evaluation of the script(s) will be compared. Note that only output printed using the global puts command is used for comparison. If -output is not specified, output sent to stdout and outputChannel is not processed for comparison.

-errorOutput expectedValue

The -errorOutput attribute supplies the expectedValue against which any output sent to stderr or errorChannel during evaluation of the script(s) will be compared. Note that only output printed using the global puts command is used for comparison. If -errorOutput is not specified, output sent to stderr and errorChannel is not processed for comparison.

-returnCodes expectedCodeList

The optional -returnCodes attribute supplies expectedCodeList, a list of return codes that may be accepted from evaluation of the -body script. If evaluation of the -body script returns a code not in the expectedCodeList, the test fails. All return codes known to return, in both numeric and symbolic form, including extended return codes, are acceptable elements in the expectedCodeList. Default value is “ok return”.

-errorCode expectedErrorCode

The optional -errorCode attribute supplies expectedErrorCode, a glob pattern that should match the error code reported from evaluation of the -body script. If evaluation of the -body script returns a code not matching expectedErrorCode, the test fails. Default value is “*”. If -returnCodes does not include error it is set to error.

To pass, a test must successfully evaluate its -setup, -body, and -cleanup scripts. The return code of the -body script and its result must match expected values, and if specified, output and error data from the test must match expected -output and -errorOutput 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 test.

As long as test 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 outputChannel. In default operation, a successful test produces no output. The output messages produced by test are controlled by the configure -verbose option as described in CONFIGURABLE OPTIONS below. Any output produced by the test scripts themselves should be produced using puts to outputChannel or errorChannel, so that users of the test suite may easily capture output with the configure -outfile and configure -errfile options, and so that the -output and -errorOutput attributes work properly.

configure -constraints knownBug \


          -limitconstraints true \


          -verbose pass

CONFIGURABLE OPTIONS

The configure command is used to set and query the configurable options of tcltest. The valid options are:

-singleproc boolean

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

-debug 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 configure -outfile. Default value is 0. Levels are defined as:

-verbose level

Sets the type of output verbosity desired to level, a list of zero or more of the elements body, pass, skip, start, error, line, msec and usec. Default value is “body error”. Levels are defined as:

-preservecore level

Sets the core preservation level to level. This level determines how stringent checks for core files are. Default value is 0. Levels are defined as:

-limitconstraints boolean

Sets the mode by which test honors constraints as described in TESTS above. Default value is false.

-constraints list

Sets all the constraints in list to true. Also used in combination with configure -limitconstraints true to control an alternative constraint mode as described in TESTS above. Default value is an empty list.

-tmpdir directory

Sets the temporary directory to be used by makeFile, makeDirectory, viewFile, removeFile, and removeDirectory as the default directory where temporary files and directories created by test files should be created. Default value is workingDirectory.

-testdir directory

Sets the directory searched by runAllTests for test files and subdirectories. Default value is workingDirectory.

-file patternList

Sets the list of patterns used by runAllTests to determine what test files to evaluate. Default value is “*.test”.

-notfile patternList

Sets the list of patterns used by runAllTests to determine what test files to skip. Default value is “l.*.test”, so that any SCCS lock files are skipped.

-relateddir patternList

Sets the list of patterns used by runAllTests to determine what subdirectories to search for an all.tcl file. Default value is “*”.

-asidefromdir patternList

Sets the list of patterns used by runAllTests to determine what subdirectories to skip when searching for an all.tcl file. Default value is an empty list.

-match patternList

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

-skip patternList

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

-load script

Sets a script to be evaluated by loadTestedCommands. Default value is an empty script.

-loadfile filename

Sets the filename from which to read a script to be evaluated by loadTestedCommands. This is an alternative to -load. They cannot be used together.

-outfile filename

Sets the file to which all output produced by tcltest should be written. A file named filename will be opened for writing, and the resulting channel will be set as the value of outputChannel.

-errfile filename

Sets the file to which all error output produced by tcltest should be written. A file named filename will be opened for writing, and the resulting channel will be set as the value of errorChannel.

CREATING TEST SUITES WITH TCLTEST

The fundamental element of a test suite is the individual test command. 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 $::tcl_platform(user)

At the next higher layer of organization, several test commands are gathered together into a single test file. Test files should have names with the “.test” extension, because that is the default pattern used by runAllTests 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 test commands. Use constraints to skip tests, rather than conditional evaluation of test.

[5]

Recommended system for writing conditional tests, using constraints to guard:

testConstraint X [expr $myRequirement]
test goodConditionalTest {} X {


    # body
} result

[6]

Discouraged system for writing conditional tests, using if to guard:

if $myRequirement {


    test badConditionalTest {} {


        #body


    } result
}

Use the -setup and -cleanup 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 -setup and -cleanup options. This is a better solution than performing setup outside of test 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 configure -singleproc 1 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 test 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 main runAllTests. This means that each test file should process command line arguments to give the tester all the configuration control that tcltest provides.

After all tests in a test file, the command cleanupTests should be called.

[7]

Here is a sketch of a sample test file illustrating those points:

package require tcltest 2.5
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 runAllTests after doing any necessary setup. This script is usually named all.tcl because that is the default name used by runAllTests when combining multiple test suites into one testing run.

[8]

Here is a sketch of a sample test suite main script:

package require Tcl 8.6
package require tcltest 2.5
package require example
::tcltest::configure -testdir \


        [file dirname [file normalize [info script]]]
eval ::tcltest::configure $argv
::tcltest::runAllTests

COMPATIBILITY

A number of commands and variables in the ::tcltest namespace provided by earlier releases of tcltest have not been documented here. They are no longer part of the supported public interface of tcltest 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, configure will be automatically called shortly after package require tcltest 2.1 succeeds with arguments from the variable ::argv. This is to support test suites that depend on the old behavior that tcltest was automatically configured from command line arguments. New test files should not depend on this, but should explicitly include

eval ::tcltest::configure $::argv

or

::tcltest::configure {*}$::argv

to establish a configuration from command line arguments.

KNOWN ISSUES

There are two known issues related to nested evaluations of test. 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 tests have been run, results will only be reported by cleanupTests 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 intercepted by redefining the global 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 -output and -errorOutput options to test is useful only for pure Tcl applications that use puts to produce output.

KEYWORDS

test, test harness, test suite