[Python-ideas] ABC: what about the method arguments ?

Andrew Bennetts andrew at bemusement.org
Fri Sep 24 07:58:00 CEST 2010

Terry Reedy wrote:
> Since unittests have been brought up, I have a idea and question.
> Can this work? Split the current test suite for a concrete class
> that implements one of the ABCs into concrete-specific and
> ABC-general portions, with the abstract part parameterized by
> concrete class.

FWIW, bzr's test suite has this facility, and bzr plugins that implement
various bzr interfaces will have tests for those interfaces
automatically applied.  (Being a Python 2.4+ project, bzr doesn't
actually use the ABCs feature, but we certainly use the concept of
"interface with many implemenations".)

E.g. if you define a new Transport (in bzr terms, a thing like FTP,
HTTP, etc) you probably want to make sure it complies with bzrlib's
expectations for Transports.  So you can include a get_test_permutations
function in your module that returns a list of (transport_class,
server_class) pairs.  [Unsurprisingly you need a test server to run
against, although for transports like LocalTransport (local filesystem
access) they can be very simple.]

It works very well, and is very useful both for bzrlib itself and
plugins.  We have “per-implementation” tests for: branch, bzrdir,
repository, interrepository, merger, transport, tree, workingtree,
uifactory, and more.  Look for bzrlib/tests/per_*.

It's not necessarily easy to write all those tests.  The more complex an
interface, the more likely it is you'll have many tests for that
interface that don't really apply to all implementations — for instance
some Transports are read-only, or don't support list_dir, etc.  So tests
that involve those need to specifically check for that capability and
raise NotApplicable, and finding the exact right way to do that can be
tricky.  It's often easier to say “if isinstance(thing,
ParticularImplementation): ...”, but that quickly erodes the
applicability of those tests for new implementations.

Also tricky is when the setup or even assertions for some tests needs to
vary considerably by implementation: how complicated is your
parameterisation interface going to have to be?

bzr has found it worthwhile, so I do encourage trying it.  I'd use
Robert Collins' http://launchpad.net/testscenarios library if I were
providing this infrastructure in a suite that doesn't already have this
approach; it's basically a distillation of the infrastructure developed
in bzrlib.tests.


More information about the Python-ideas mailing list