«

On Wed, 22 Dec 2004 02:27:35 +0200, Noam Raphael <> wrote:
>Jeff Shannon wrote:
> > In the context of changing an existing interface, a unit-testing
> > scenario would mean that, instead of installing a "pure virtual" method
> > on a base class, you'd change the unit-tests to follow the new
> > specification, and then write code that would pass the unit tests. If
> > you are subclassing from a common base, then you'd only need to change
> > the unit test for that common base class (presuming that all derived
> > classes would run those unit tests as well).
> >
> The problem is that I couldn't write a general unit test, since the base
> class wasn't instantiable - there wasn't even any point in making it
> instantiable, since every subclass was constructed with different
> argument definition. They were just required to provide some methods
> (check whether they contain an object, for example) - I don't know how
> to write a unit test for such a base class, or what does it mean. (Well,
> it may mean: check whether all the required methods exist, but come on -
> that's exactly the idea of my suggestion. There's no point in having to
> write the list of required methods another time).

from harness import TestCase

class FoobarTestCase(TestCase):
def instanceFactory(self):
raise NotImplementedError()

def testBazMethod(self):
inst = self.instanceFactory()
self.assertEquals(inst.baz(), 'baz')
...

class QuuxTestCase(FoobarTestCase):
def instanceFactory(self):
return Quux(x=y, a=b)

class WibbleTestCase(FoobarTestCase):
def instanceFactory(self):
return Wibble(1, 2, 3)

This lets you avoid duplicate test code as well as easily test
new concrete implementations. It's an ideal approach for frameworks
which mandate application-level implementations of a particular
interface and want to ease the application developer's task.

Jp

Jp Calderone wrote:
> This lets you avoid duplicate test code as well as easily test
> new concrete implementations. It's an ideal approach for frameworks
> which mandate application-level implementations of a particular
> interface and want to ease the application developer's task.
>
> Jp

It's a great way for sharing tests between different subclasses of a
class. Thank you for teaching me.

However, I'm not sure if this solves my practical problem - testing
whether all abstract methods were implemented. I think that usually, you
can't write a test which checks whether an abstract method did what it
should have, since different implementations do different things. I
don't even know how you can test whether an abstract method was
implemented - should you run it and see if it raises a
NotImplementedError? But with what arguments? And even if you find a way
to test whether a method was implemented, I still think that the
duplication of code isn't very nice - you have both in your class
definition and in your test suite a section which says only "method
so-and-so should be implemented."

I think that making abstract methods a different object really makes
sense - they are just something else. Functions (and methods) define
what the computer should do. Abstract methods define what the
*programmer* should do.

Again, thanks for enlightening me.
Noam