0

This is an extension of: Unit Testing Interfaces in Python

My problem is the number of classes that satisfy an interface will eventually run into the thousands. Different developers work on different sub classes.

We can't have a failing unit test for one subclass fail tests for other sub classes. Essentially, I need to create a new unittest.TestCase type for each subclass satisfying the interface.

It would be nice to be able to do this without having to modify the test module. (I'd like to avoid updating the unit test module every time a new subclass satisfying the interface is added).

I want to be able to create a unittest.TestCase class type automatically for a class satisfying interface. This can be done using meta classes.

But these classes need to be added to the test module for testing. Can this be done during class definition without requiring modifications to the test module?

Community
  • 1
  • 1
GeneralBecos
  • 2,476
  • 2
  • 22
  • 32
  • 1
    Really? Thousands of subclasses? That sounds like a wrong solution, and you could do it differently in the first place. Also, the first answer to your linked to question is "nosetest test generation." Why is that not the answer to your problem? – Ned Batchelder Jul 01 '12 at 18:56
  • Yeah, we are working on extremely varied data. Nose test generation would require updating the test module every time a new sub class is written. – GeneralBecos Jul 01 '12 at 19:13

1 Answers1

0

If you are writing separate subclasses, there must be differences among them that will need to be tested in addition to their successful implementation of the interface. Write a method called satisfies_the_thousand_class_interface that tests the interface, add it to your custom TestCase class, then have each of your thousand test cases (one for each subclass) also invoke that method in addition to all of the specialized testing they do.

Ned Batchelder
  • 364,293
  • 75
  • 561
  • 662
  • They are essentially just satisfying an interface. I don't want to test their unique functionality. – GeneralBecos Jul 01 '12 at 19:11
  • You have thousands of classes are you aren't interested in testing how they are different from each other? Now I'm really convinced you are doing this wrong... – Ned Batchelder Jul 01 '12 at 19:12
  • Their implementation of the interface is different. – GeneralBecos Jul 01 '12 at 19:14
  • To give you a bit more color, we are working with financial instruments. Each instrument is priced differently but the output is a valid testable number. We are testing this output against the pricing interface. – GeneralBecos Jul 01 '12 at 19:17
  • Why isn't that one class with a number of parameters, and you instantiate it differently to produce different instruments? – Ned Batchelder Jul 01 '12 at 19:18
  • Because nobody has enough expertise to know all instruments. – GeneralBecos Jul 01 '12 at 19:19
  • Besides, imagine the number of edits happening to this one class. Breaking this one class breaks all instruments. – GeneralBecos Jul 01 '12 at 19:20
  • OK, but still, a dozen or so classes should be able to cover it? I just don't see how you can write code for thousands of classes, and not need to write tests for thousands of classes. If they aren't different enough to test, they aren't different enough to write. – Ned Batchelder Jul 01 '12 at 19:20
  • let us [continue this discussion in chat](http://chat.stackoverflow.com/rooms/13277/discussion-between-generalbecos-and-ned-batchelder) – GeneralBecos Jul 01 '12 at 19:21