I'd like to do some refactoring of svntest. The impetus for these ideas
came from the difficulty I had in the cvs2svn project in creating
multiple test cases with slight variations. I would have liked to pass
callable class instances to main.run_tests() instead of function
objects, so that I could store auxiliary information in the class
instances. This was not possible because the svntest infrastructure is
too rigid: it insists that test cases be based on naked function objects.
Here is a rough sketch of my proposal:
- Create an "abstract public" class testcase.Predicate that describes
the required interface of a Predicate without making any implementation
restrictions (e.g., without requiring that it be based on a naked
function object).
- Change main.run_tests() to accept either objects inheriting from
Predicate, *or* function objects. The latter would be converted to
Predicates using...
- Add a new factory function testcase.create_predicate(), which would
try to create a Predicate out of its argument. If the argument already
inherited from Predicate, it would be returned unchanged. If it is a
function, it would be wrapped in a new class...
- Add a new class FunctionPredicate, which would be like the old
_Predicate class but would inherit from Predicate. This class would
wrap a function object as a Predicate, and would be responsible for
digging around in the function internals to find the doc string, to
decide whether the function needs a sandbox argument, etc.
- Change XFail and Skip to be wrapper classes that (1) inherit from
Predicate, (2) can accept any Predicate as an argument (or a function,
which would be wrapped using create_predicate()), (3) delegate to the
Predicate object instead of taking over its identity.
I think that this can all be done without making any
non-backwards-compatible changes to the public interface of svntest.
What do you think? Does anybody have any objections or foresee any
problems with particular client code?
Michael
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Apr 4 06:25:21 2006