[TIP] How do I run the same test on many different classes?
olemis at gmail.com
Mon Dec 14 05:49:56 PST 2009
On Sun, Dec 13, 2009 at 2:45 PM, Matthew Wilson <matt at tplus1.com> wrote:
> This is one of those problems that I know how to solve in an ugly way,
> but I want to learn a better way.
> I need to write a class that acts like a dictionary with some other
> tweaks bolted on.
First of all , there's a way (in stdlib test suite ;o) to test that
custom mapping objects conform to the protocol ...
> I wrote a single unittest.TestCase class that tests for all the
> features I care about. Pretend that the TestCase subclass is called
> TestTask and the class I want to make will be named Task.
> I have several ideas about how to build this class and I want to use
> the TestTask class as a pass-fail filter. Pretend I'll name each idea
> Task1, Task2, Task3, etc.
> Then I want to pass Task1, Task2, etc into unittest.TestCase so it
> would run the tests on an instance of that class.
> I experimented with something like this:
> >>> import task, test_task, unittest
> >>> Task = task.Task1
> >>> tl = unittest.TestLoader()
> >>> tl.loadTestsFromModule(test_task)
> >>> suite = tl.loadTestsFromModule(test_task)
> >>> unittest.TextTestRunner().run(suite)
> Of course, that blows up because my test_task.TestTask class depends
> on a global Task class that isn't defined when I defined that module.
I am supposing that you want to write (abstract) test cases once and
execute (real) tests using instances of different concrete classes
that have to behave the same way . If this is the case then I can
suggest you two things :
- take a look at the stdlib tests for mapping objects I mentioned before
- Write a loader that instantiates the test suite once and then
clone (deep copy) it
for each concrete concrete class. This is the approach I employed
to perform a
benchmarking for design by contract libraries . DBC semantics are
same so they all have to do things the same way too ;o)
I've mentioned that before several times , searching the archive might give
you further ideas ;o)
If I didn't understand or am missing something , please let me know ;o)
Blog ES: http://simelo-es.blogspot.com/
Blog EN: http://simelo-en.blogspot.com/
olemis changed the public information on the FLiOOPS project -
More information about the testing-in-python