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