On Wed, 22 Dec 2004 02:27:35 +0200, Noam Raphael <[EMAIL PROTECTED]> 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
--
http://mail.python.org/mailman/listinfo/python-list
