Idea for svntest refactoring

[Michael Haggerty <mh...@alum.mit.edu>]

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

Re: Idea for svntest refactoring

[Garrett Rooney <ro...@electricjellyfish.net>]

On 4/3/06, Michael Haggerty <mh...@alum.mit.edu> wrote:

> What do you think?  Does anybody have any objections or foresee any
> problems with particular client code?

Sounds reasonable to me, go for it!

-garrett

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: Idea for svntest refactoring

[Branko Čibej <br...@xbc.nu>]

Michael Haggerty wrote:
> 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.
>   
The idea sounds great.

However ...  I do have one objection -- terminological rather than 
technical. Calling the test functor a "predicate" is wrong -- it isn't a 
predicate (XFail and Skip are -- see 
http://en.wikipedia.org/wiki/Predicate, fourth item). I'd call it a 
TestFunctor (http://en.wikipedia.org/wiki/Function_object).

Yes, I know that I originally created the private class _Predicate in 
testcase.py; but that _is_ a predicate, it wraps the test case in a test 
(admittedly a no-op test by default).

You'll still need both predicates (for XFail and Skip) and functors (for 
the test case implementations).

-- Brane


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org