ToC | DocOverview | CGDoc | RelNotes | FAQ | Index | PermutedIndex
| Allegro CL version 11.0

# inc-test-counter

macro, util.test package

Arguments: name-of-counter &optional (increment 1)

Increment one of the test counters, atomically if necessary. A test application that may modify these test counters in multiple threads must use this macro to make sure the modification is done atomically.

The name-of-counter argument must be the name of one of the three test counters, *test-successes*, *test-errors*, or *test-unexpected-failures*.

# test

macro, util.test package

Arguments: expected-value test-form &key (test #'eql) multiple-values fail-info known-failure

Perform a single test. expected-value is the reference value for the test. test-form is a form that will produce the value to be compared (using the predicate that is the value of the test keyword argument) to expected-value. If the values are not the same, then a failure is logged; otherwise a success is logged.

The comparison is done with the predicate that is the value of the test keyword argument. The default value of test is eql. Other standard comparison functions include eq, equal, equalp, string=, string-equal, etc., and you may, of course, write your own predicate.

Normally, only the first return value from the test-form is considered, however if multiple-values is t, then all values returned from test-form are considered. If multiple-values is true, expected-values must be a list. If the length of the expected-value list differs from the number of returned values, the test will fail.

The value of the fail-info argument should be nil or a string. If a string, it is printed if the test fails, providing more information with a test failure. (Typical strings are "bug2127" and "can fail when network is slow".)

known-failure if true, affects what is printed when the test fails or succeeds. Thus a failure is reported as "Test failed: known failure: ..." and a success as "Expected test failure for [...] did not occur."

See test-harness.html for information on the Allegro CL test harness.

# test-error

macro, util.test package

Arguments: form &key announce catch-breaks fail-info known-failure (condition-type 'simple-error) include-subtypes format-control format-arguments

Test that form signals an error. The order of evaluation of the arguments is keywords first, then form.

If announce is non-`nil`, then cause the error message to be printed.

If the catch-breaks is non-`nil` then consider a call to common-lisp:break an error.

The value of the fail-info argument should be nil or a string. If a string, it is printed if the test fails, providing more information with a test failure. (Typical strings are "bug2127" and "can fail when network is slow".)

known-failure if true, affects what is printed when the test fails or succeeds. Thus a failure is reported as "Test failed: known failure: ..." and a success as "Expected test failure for [...] did not occur."

The value of condition-type must be a symbol naming a condition type (`nil` is not an acceptable value). The condition type is used to check against the signaled condition type. The test will fail if they do not match. Note: the default is simple-error so if this argument is unspecified, the test will fail if an error that is not a simple-error is signaled. If you want any error, specify the value of this argument error and the value of include-subtypes t.

include-subtypes, used with condition-type, can be used to match a condition to an entire subclass of the condition type hierarchy.

format-control and format-arguments can be used to check the error message itself. The comparison is done with equal.

See test-harness.html for information on the Allegro CL test harness.

# test-no-error

macro, util.test package

Arguments: form &key announce catch-breaks fail-info known-failure

Test that form does not signal an error. The order of evaluation of the arguments is keywords first, then form.

If announce is non-`nil`, then cause the error message to be printed.

If the catch-breaks is non-`nil` then consider a call to common-lisp:break an error.

The value of the fail-info argument should be nil or a string. If a string, it is printed if the test fails, providing more information with a test failure. (Typical strings are "bug2127" and "can fail when network is slow".)

known-failure if true, affects what is printed when the test fails or succeeds. Thus a failure is reported as "Test failed: known failure: ..." and a success as "Expected test failure for [...] did not occur."

See test-harness.html for information on the Allegro CL test harness.

# test-no-warning

macro, util.test package

Arguments: form &key fail-info known-failure

Test that form does not signal a warning. The order of evaluation of the arguments is keywords first, then form.

The value of the fail-info argument should be nil or a string. If a string, it is printed if the test fails, providing more information with a test failure. (Typical strings are "bug2127" and "can fail when network is slow".)

known-failure if true, affects what is printed when the test fails or succeeds. Thus a failure is reported as "Test failed: known failure: ..." and a success as "Expected test failure for [...] did not occur."

See test-harness.html for information on the Allegro CL test harness.

# test-warning

macro, util.test package

Arguments: form &key fail-info known-failure

Test that form signals a warning. The order of evaluation of the arguments is keywords first, then form.

The value of the fail-info argument should be nil or a string. If a string, it is printed if the test fails, providing more information with a test failure. (Typical strings are "bug2127" and "can fail when network is slow".)

known-failure if true, affects what is printed when the test fails or succeeds. Thus a failure is reported as "Test failed: known failure: ..." and a success as "Expected test failure for [...] did not occur."

See test-harness.html for information on the Allegro CL test harness.

# with-tests

macro, util.test package

Arguments: (&key (name "unnamed")) &body body

The body should be test forms. At the end of execution of the body, a report is generated which summarizes successes and failures.

with-tests binds *test-successes*, *test-errors*, and *test-unexpected-failures* to 0 before the execution of body and the printing of the results.

name is printed with the results -- "Begin test", so "Begin unnamed test" if unspecified.

Multiprocessing note: when tests run in multiple threads, the counters bound by an occurrence of the with-tests macro accumulate counts only from tests running in the same thread. If code within the scope of a with-tests macro starts another thread where tests may also run, the latter tests will increment the global counters (or some other with-tests scope).

See test-harness.html for information on the Allegro CL test harness.

Copyright (c) Franz Inc. Lafayette, CA., USA. All rights reserved.

ToC | DocOverview | CGDoc | RelNotes | FAQ | Index | PermutedIndex
| Allegro CL version 11.0