I have been backporting Gary's markdown documentation to texinfo, and came across this:
This operation should test the specified component. ASDF does not (currently) provide a method for returning a value from the test-op (or any other operation), so the implementor must ensure that executing test-op has the side effect of printing useful information about the tests to the CL stream *standard-output*.
Question: do we want to specify *standard-output* as the destination for test-op output?
I find that to be undesirable because on many CL implementations, it leads to test output being interspersed with lots of messages from compilation and loading, which makes it hard to find the test output you're looking for.
I don't like specifying *standard-output* as the destination because it seems to me to be committing us to a bad solution. I think here /not/ specifying a destination is better than specifying a bad destination.
I've never found a satisfactory solution to this problem. One suggestion would be to have the test-op take an init arg that specifies a stream (or a filename?) to which test output should be written. It would be left to test op implementers to figure out how to get their test output to go to that destination. I imagine this would typically be achieved by having the PERFORM method dynamically bind some variable that designates the destination.
So, two proposals:
1. Delete the specification of *standard-output* as destination.
2. Add an initarg and slot for test-op and specify that output should go there.
These are actually two somewhat independent proposals. A 'Yes' on 2 entails a 'Yes' on 1, but it's possible to say 'Yes' to 1 and 'No' to 2.
Best, R