I have just pushed to the docs topic branch a complete rewrite of the recommendations for TEST-OP.
I think this rewrite better maintains abstraction, because the testing methods are on the test library, rather than on the library to be tested. I also explained why one should have a separate test library.
I have abandoned any attempt at ASDF 2 compatibility, also. It makes the presentation too cumbersome and twisty.
I welcome inspection of this changed definition and suggestions for improvement.
Best, r
On Sun, Apr 6, 2014 at 12:03 PM, Robert P. Goldman rpgoldman@sift.info wrote:
I have just pushed to the docs topic branch a complete rewrite of the recommendations for TEST-OP.
I think this rewrite better maintains abstraction, because the testing methods are on the test library, rather than on the library to be tested. I also explained why one should have a separate test library.
I have abandoned any attempt at ASDF 2 compatibility, also. It makes the presentation too cumbersome and twisty.
I welcome inspection of this changed definition and suggestions for improvement.
Yes, I think we should stop documenting ASDF 2 compatibility, and instead suggest that people should upgrade their implementation, or, if stuck with LispWorks, and until it is released with ASDF 3 as is planned later this year, use our bin/install-asdf-as-module script. The odd case of a user being stuck with a system-provided implementation the asdf of which can't be upgraded and without quota to install a new one should be marginal not to deserve more than a footnote or a FAQ at best.
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org My Halloween Costume: Civil Servant from the Department of Being Here to Help You (with Other People's Money). PS: you're the Other People, not "You".