Juan Jose Garcia-Ripoll wrote:
On Mon, Oct 19, 2009 at 12:00 AM, Robert Goldman rpgoldman@sift.info wrote:
In particular because it's my impression that the problems have been over-stated.
I think so. And this is indicated by the following paragraphs
[..snip..]
- One needs to come up with a means of combining operation results
that takes into account the structure of the plan that traverse produces and that operate then executes. If in order to test-op X, I must test-op A and B, how do I combine together the test results from A, B, and X into a top-level operation result. Perhaps OPERATION-ANCESTOR can be pressed into service.
You are just imposing too much complexity. If I want to test package Cl-UNICODE, I do nont want to test FLEXI-STREAMS or U-SOCKETS. Tests should be atomic and not generate a tree of actions like ASDF does not for everything.
Please see earlier discussion about this topic.
The point I made there is that systems may have COMPONENT subsystems such that you want to test the entire system together.
Consider, e.g., a DB library with multiple backends, each described in a separate system. In order to do the test-op on the DB library you want to do the test on all active backends. Similarly, McCLIM has multiple graphics display backends, not all of which are loaded at a given time. I work actively on three (or four, depending on how you count) large CL-based applications. Each one of them is made up of multiple ASDF subsystems.
The example of CL-UNICODE is a strawman, because it is the case of testing a system and its libraries. There is also the case of testing a system and its subsystems, which is the more interesting one.
For that matter, though, if I am a CL-UNICODE /user/, I may very well want to test to see if it will work in its current installation, in which case I /do/ want to test FLEXI-STREAMS and U-SOCKETS, because I want to know whether my installation works.
[..snip..]