[asdf-devel] ASDF test-op question

Robert Goldman rpgoldman at sift.info
Thu Oct 8 23:40:02 UTC 2009


Tobias C. Rittweiler wrote:
> Robert Goldman writes:
> 
>> Tobias C. Rittweiler wrote:
>>> Robert Goldman writes:
>>>
>>>> 2.  Returning a single operation isn't enough, is it?  For example, if I
>>>> have system X, with sub-systems A, B, and C, I may be testing A, B, and
>>>> C, so my traversal would have to gather up the three subsidiary test-op
>>>> entities and either package them into the parent test-op object, or rip
>>>> the test results out of them and push them into the parent test-op
>>>> object.  I don't believe the plan-then-execute logic of ASDF makes this
>>>> easy, but I may be wrong.
>>> Does performing TEST-OP on a sytem really result in testing all the
>>> system's dependencies? Or did you mean something else?
>> We often have large structured systems where testing system X is done by
>> testing subsidiary systems A, B, and C that X depends on.
>>
>> Consider, for example, if one were to write a test-op for CLSQL.  One
>> might then have subsidiary systems for the various DB backends, and one
>> would have the test-op for CLSQL run the test-op on each backend (or
>> some subset of the backends that are turned on).
> 
> So CLSQL's method on TEST-OP should perform tests on each backend and
> then merge the results of the subsystems into one result, shouldn't it?

That's one way of doing it, I suppose.  We typically do something like:

(:in-order-to ((test-op (test-op comp1)) (test-op (test-op comp2)) ...))

Yes, one can work around that, and hand-code more, but I'd prefer not to.

OTOH, I'm coming to the conclusion that ASDF simply doesn't offer a good
enough solution to this problem, and fixing it in ASDF won't benefit
enough ASDF users.  The different use patterns, and different underlying
test libraries seem to diverge enough that we should all fix this ourselves.

best,
r




More information about the asdf-devel mailing list