Re: XCVB, a replacement for ASDF

"Robert P. Goldman" <[email protected]> Mon, 02 Jun 2008 08:09:09 -0500
Newsgroups gmane.lisp.cclan.general
Organization SIFT, LLC
Message-ID <[email protected]>
Attila Lendvai wrote:
>> 2.  The test operation's semantics are unclear.  What should happen when
>> one tests a component?  What is the contract the implementer should be
>> making with user of the test system?  Should the test operation hurl
>> errors?  It cannot return values.  Should it write output somewhere for
>> later inspection?  If so, where should that output be written?  Ideally,
>> we should find a contract that would accommodate the use of many
>> different testing frameworks.
> 
> 
> i have these all around in my systems:
> 
> (defmethod operation-done-p ((op test-op) (system (eql (find-system
> :cl-rdbms))))
>   nil)
> 
> about return values from operation: stefil is our test system. it's
> basically a defun* that generates instrumented defuns that ensure a
> test environment, plus some operators that record info in this env.
> when you start such a defun, it'll mix in the collected test
> environment as an nth+1 value into the return values. this is a clos
> object that has a customized slime inspector...
> 
> so stefil pretty much relies on return values and currently i often
> C-c C-c the test-op, and start the tests from the repl, only to be
> able to inspect the test results at the end.
> 

Our test-op writes output, as do a number of others.  After finding that
the test-op's output would often get lost in the compiler's messages, I
wrote some code to allow asdf's test-op to take an initarg that would
write its output to a special destination.  That experience led to many
of my conclusions in the earlier message.  In particular the fact that
it was difficult to provide a subclass of test-op and then flow that
subclass up --- in the end I found it easier to revise the test-op class
on the fly and add a new slot to it, or things got very hairy with
classes with nested test-ops.

Best,
R


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