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

Olemis Lang olemis at gmail.com
Fri Feb 12 15:16:36 CET 2010

On Tue, Feb 9, 2010 at 2:04 PM, Michael Foord <fuzzyman at voidspace.org.uk> wrote:

On 09/02/2010 19:00, Olemis Lang wrote:

Sorry. I had not finished the previous message On Tue, Feb 9, 2010 at 1:55 PM, Olemis Lang<olemis at gmail.com>  wrote: On Tue, Feb 9, 2010 at 1:29 PM, Olemis Lang<olemis at gmail.com>  wrote: On Tue, Feb 9, 2010 at 11:42 AM, Michael Foord <fuzzyman at voidspace.org.uk>  wrote:

Hello all,

Several authors of other Python testing frameworks spoke up against them, but several users of test frameworks spoke up in favour of them. ;-)

+1 for having something like that included in unittest I'm pretty sure I can introduce setUpClass and setUpModule without breaking compatibility with existing unittest extensions or backwards compatibility issues Is it possible to use the names BeforeClass and AfterClass (just to be make it look similar to JUnit naming conventions ;o) ? Another Q:  - class setup method will be a classmethod isn't it ? It should not be a regular instance method because IMO it is not bound to a particular TestCase instance. - Is it possible to rely on the fact that all class-level tear down methods will be guaranteed to run even if class-level setup method throws an exception ? Yes it will be a classmethod rather than an instance method.

+1

I would expect that in common with instance setUp the tearDown would not be run if setUp fails. What would be nice would be an extension of addCleanUp so that it can be used by class and module level setUp. Clean-ups largely obsolete the need for tearDown anyway.

I really disagree. IMO I am -1 for having addCleanUp and so on added to the core API (i.e. TestCase class). The same goes for test resources (especially if that means to merge it with the API rather than including it as a separate independent module). The use cases for that feature are not, in general, basic use cases ('cause if they were simple, setUp/tearDown would be a simple alternative to do the same thing ;o).

I repeat that my opinion is that I am -1 for including each and every feature needed for testing purposes jus because it's very (super) useful to solve even many use cases (e.g. context managers, by themselves, are an empty and abstract construct that solve a set of problems once they are implemented, but the top-level abstractions are not directly useful by themselves). It's an API. In JUnit there are a lot of useful extensions implemented in junit-ext package & Co. (and AFAICR that also includes integration testing & test resources) and besides there are some other important features in JUnit>=4.7 itself, but not hard coded in TestCase (e.g. org.junit.rules.ExternalResource, ...) and also allowing extensions (e.g. org.junit.rules.TemporaryFolder) using well established mechanisms (e.g. inheritance) . This also has the benefit that the responsibilities are distributed to a set of relevant objects following well-known interaction patterns, rather than cluttering a class with all sort of functionalities .

PS: I say this and I know that it's quite unlikely that you will reconsider it in order to revert what's being done there . But, if we take a look to JUnit>=4.7, just notice that resource management is not an integral part of TestCase at all, and is performed in a more structured way, consistent with the «standard» or officially supported mechanism used to add any other extension to JUnit . Honestly I can obviously see the differences with respect to addCleanUp implementation as we know it today.

-- Regards,

Olemis.

Blog ES: http://simelo-es.blogspot.com/ Blog EN: http://simelo-en.blogspot.com/

Featured article: TracGViz plugin downloaded more than 1000 times (> 300 from PyPI) - http://feedproxy.google.com/r/simelo-en/3/06Exn-JPLIA/tracgviz-plugin-downloaded-more-than.html

More information about the Python-Dev mailing list