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/