[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Idea for svntest refactoring

From: Michael Haggerty <mhagger_at_alum.mit.edu>
Date: 2006-04-04 06:24:33 CEST

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

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.