ASDF test-op

In an earlier email, I proposed that we modify the ASDF test-op so that
it have a stream slot and initarg.  The problem this is intended to fix
is that when one runs an asdf test-op, there's no easy way to tell
whether it has succeeded or failed.  In particular, with the current
structure of ASDF, there's no easy way to return a value or values
indicating the results.  Further, if you build your test-op on top of
some unit testing framework, you are likely to find that the output of
your unit test is mixed in with the output of the compiler.

Here's what I've done for one of my systems:

(defclass asdf::stream-test-op (test-op)
     ((result-stream
       :initarg :result-stream
       :reader result-stream
       :initform t
       :documentation "Stream to which output should be written."
       ))
  (:documentation "A subclass of the test-op that includes a stream to
which test
output should be written.")
  )

Note that if this were to be added to the standard asdf distribution, it
would break *no* existing code, since anyone implementing a test-op is
free to ignore the result-stream, and anyone who wants to can use it.

Here's an example of how I was able to make an :around method on the
test-op mesh nicely with a unit-test framework:

(defmethod perform :around ((o stream-test-op) (c shop-tester))
  "Bind the output stream to the result stream."
  (let (( cl-user::*nst-default-report-stream* (result-stream o)))
    (format cl-user::*nst-default-report-stream* "~&Running test on
system: ~A~%"
	  (component-name c))
    (force-output cl-user::*nst-default-report-stream*)
    (call-next-method)
    (format cl-user::*nst-default-report-stream* "~&test on system ~A
completed.~%"
	  (component-name c))
    ))

OK, if it's easy to do this kind of thing with your own subclass of
asdf:test-op, why should this be put in the standard distribution.  I
can think of two benefits and, as I pointed out above, the downside in
terms of breakage of existing code seems to be nil.

1.  It provides a protocol for asdf library *users* to exploit.  If we
don't have this, then the humble asdf user has to dig into the asdf file
to figure out how to use the test-op.  I think it's more reasonable to
just make it easy.  Indeed, ideally, I'd like it to be possible for
someone using asdf-install to get a reasonable test-op output.  But that
may be asking a lot...  Still, it's something that the CPAN folks have
managed.

2.  It provides some sort of expectation for what a test-op implementer
should do.  Right now there's an understanding that there should *be* a
test-op, but we don't know how to code to this expectation (compare the
earlier thread -- how concluded? -- on the subject of operation-done-p
and test-op).

This is not a fully polished revision proposal, but I think it's worthy
to start a discussion...

Best,
Robert


-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/