Commit b1b2f78a authored by Robert P. Goldman's avatar Robert P. Goldman

Rewrite description of TEST-OP.

parent d19a46a9
......@@ -1863,6 +1863,8 @@ To see what @code{operate} would do, you can use:
@node Predefined operations of ASDF, Creating new operations, Operations, Operations
@comment node-name, next, previous, up
@subsection Predefined operations of ASDF
@c FIXME: All these deffn's should be replaced with deftyp. Also, we
@c should set up an appropriate index.
All the operations described in this section are in the @code{asdf} package.
They are invoked via the @code{operate} generic function.
......@@ -1912,7 +1914,7 @@ may be performed on a given component.
@deffn Operation @code{load-source-op}, @code{prepare-source-op}
@code{load-source-op} will load the source for the files in a module
rather than they compiled fasl output.
rather than the compiled fasl output.
It has a @code{prepare-source-op} analog to @code{prepare-op},
that ensures the dependencies are themselves loaded via @code{load-source-op}.
......@@ -1945,28 +1947,34 @@ The results of this operation are not defined by ASDF.
It has proven difficult to define how the test operation
should signal its results to the user
in a way that is compatible with all of the various test libraries
and test techniques in use in the community.
People typically define @code{test-op} methods like thus:
@example
(defmethod perform ((o asdf:test-op)
(s (eql (asdf:find-system @var{:my-system}))))
(asdf:load-system @var{:my-system-test})
(funcall (read-from-string "my-system-test:test-suite")))
@end example
and test techniques in use in the community, and
given the fact that ASDF operations do not return a value indicating
success or failure.
For those willing to go to the effort, we suggest defining conditions to
signal when a @code{test-op} fails, and storing in those conditions
information that describes which tests fail.
People typically define a separate test @emph{system} to hold the tests.
Doing this avoids unnecessarily adding a test framework as a dependency
on a library. For example, one might have
@lisp
(defsystem foo
:in-order-to ((test-op (test-op "foo/test")))
...)
Using @code{load-system} in the perform method
rather than an @code{:in-order-to} dependency,
is sometimes necessary for backward compatibility with ASDF 2 and older,
to avoid circular dependencies that could arise
because of the way these old versions propagate dependencies.
(defsystem foo/test
:depends-on (foo fiveam) ; fiveam is a test framework library
...)
@end lisp
If you don't care for compatibility with ASDF 2,
you could use the following options in your @code{defsystem} form:
@example
:in-order-to ((test-op (load-op :my-system-test)))
:perform (test-op (o c) (symbol-call :my-system-test :test-suite))
@end example
Then one defines @code{perform} methods on
@code{test-op} such as the following:
@lisp
(defmethod perform ((o asdf:test-op)
(s (eql (asdf:find-system @var{:foo/test}))))
(funcall (intern (symbol-name '#:run!) :fiveam)
(intern (symbol-name '#:foo-test-suite) :foo-tests)))
@end lisp
@end deffn
@deffn Operation @code{fasl-op}, @code{monolithic-fasl-op}, @code{load-fasl-op}, @code{binary-op}, @code{monolithic-binary-op}, @code{lib-op}, @code{monolithic-lib-op}, @code{dll-op}, @code{monolithic-dll-op}, @code{program-op}
......
Markdown is supported
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment