[Python-Dev] setUpClass and setUpModule in unittest (original) (raw)

Michael Foord fuzzyman at voidspace.org.uk
Thu Feb 11 17:08:54 CET 2010

On 11/02/2010 15:56, R. David Murray wrote:

On Thu, 11 Feb 2010 12:41:37 +0000, Michael Foord<fuzzyman at voidspace.org.uk> wrote:

On 11/02/2010 12:30, Nick Coghlan wrote:

The test framework might promise to do the following for each test:

with getmodulecm(testinstance): # However identified with getclasscm(testinstance): # However identified with testinstance: # ** testinstance.testmethod() Well that is effectively how they would work (the semantics) but I don't see how that would fit with the design of unittest to make them work specifically like that - especially not if we are to remain compatible with existing unittest extensions. If you can come up with a concrete proposal of how to do this then I'm happy to listen. I'm not saying it is impossible, but it isn't immediately obvious. I don't see any advantage of just using context managers for the sake of it and definitely not at the cost of backwards incompatibility. I suspect that Nick is saying that it is worth doing for the sake of it, as being more "Pythonic" in some sense. That is, it seems to me that in a modern Python writing something like: @contextlib.contextmanager def foocm(testcase): testcase.bar = somecostlysetupfunction() yield testcase.bar.close() @contextlib.contextmanager def footestcm(testcase): testcase.baz = Mock(testcase.bar) yield @unittest.casecontext(foocm) @unittest.testcontext(footestcm) class TestFoo(unittest.TestCase): def testbar: foo = Foo(self.baz, testing=True) self.assertTrue("Context managers are cool") would be easier to write, be more maintainable, and be easier to understand when reading the code than the equivalent setUp and tearDown methods would be. I'm not saying it would be easy to implement, and as you say backward compatibility is a key concern.

This is quite different to what Nick specifically suggested. It also doesn't suggest a general approach that would easily allow for setUpModule as well.

However, I am hoping to be able to incorporate some or all of Test Resources as a general solution (with simple recipes for the setUpClass and setUpModule cases) - at which point this particular discussion will become moot.

All the best,

Michael Foord

-- R. David Murray www.bitdance.com

-- http://www.ironpythoninaction.com/ http://www.voidspace.org.uk/blog

READ CAREFULLY. By accepting and reading this email you agree, on behalf of your employer, to release me from all obligations and waivers arising from any and all NON-NEGOTIATED agreements, licenses, terms-of-service, shrinkwrap, clickwrap, browsewrap, confidentiality, non-disclosure, non-compete and acceptable use policies (”BOGUS AGREEMENTS”) that I have entered into with your employer, its partners, licensors, agents and assigns, in perpetuity, without prejudice to my ongoing rights and privileges. You further represent that you have the authority to release me from any BOGUS AGREEMENTS on behalf of your employer.

More information about the Python-Dev mailing list