|
Allegro CL version 11.0 |
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*.
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.
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.
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.
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.
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.
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
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.
|
Allegro CL version 11.0 |