roccomoretti@netscape.net (Rocco Moretti) writes:
Michael Hudson <mwh@python.net> wrote:
I've had another idea: give unittest_w.TestCase_w a metaclass that looks for methods called 'test_app_whatever' and arrange for such methods to be called as objectspace methods.
Sounds like a wonderful solution, but I have to confess that my eyes glaze over when trying to understand metaclasses - I probably should put more of an effort into learning about them one of these days...
I should probably be worried at the willingness with which I now reach for them.
Is using metaclasses really nessasary?
Heh. No, probably not.
Before I realized that metaclasses were involved, I first thought of using a special subclass of TestCase - probably by overloading TestCase.__call__() to appropriately wrap the function before it is run.
Yes, that would probably work. It would also mean that we wouldn't have to make testsupport.TestCase new-style which would mean we wouldn't have to steal 2.3's TestLoader, which would be a good thing.
If we can use the subclass approach, we could potentially simplify things by having two seperate TestCase subclasses, one for interpreter level and one for application level tests.
Yes, that would be one approach.
This would potentially require splitting of a single test case into two, one each for application and interpreter levels, whereas your implementation appears to allow both types of tests in the same class definition.
Yes it does. The subclassing approach could allow that, but doesn't have to. I don't feel that splitting the tests up would necessarily be a bad thing, either.
But feel free to ignore this as I haven't tried putting it into code and have no clue what the problems with it may be.
No, you've probably done a sensible job of restraining my obfuscatory tendencies! Cheers, M. -- Or here's an even simpler indicator of how much C++ sucks: Print out the C++ Public Review Document. Have someone hold it about three feet above your head and then drop it. Thus you will be enlightened. -- Thant Tessman