A RetroSearch Logo

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Search Query:

Showing content from https://mail.python.org/pipermail/python-dev/2010-February/097635.html below:

[Python-Dev] setUpClass and setUpModule in unittest

[Python-Dev] setUpClass and setUpModule in unittestexarkun at twistedmatrix.com exarkun at twistedmatrix.com
Fri Feb 12 21:20:51 CET 2010
On 07:48 pm, guido at python.org wrote:
>On Fri, Feb 12, 2010 at 7:49 AM, Michael Foord
><fuzzyman at voidspace.org.uk> wrote:
>>My *hope* is that we provide a general solution, possibly based on all 
>>or
>>part of Test Resources, with an easy mechanism for the setUpClass and
>>setUpModule but also solves the more general case of sharing fixtures
>>between tests. If that doesn't turn out to be possible then we'll go 
>>for a
>>straight implementation of setUpClass / setUpModule. I'm hoping I can 
>>get
>>this together in time for the PyCon sprints...
>
>Do you have a reference for Test Resources?

http://pypi.python.org/pypi/testresources/0.2.2
>[snip]
>
>However from this example I *cannot* guess whether those resources are
>set up and torn down per test or per test class. Also the notation

The idea is that you're declaring what the tests need in order to work. 
You're not explicitly defining the order in which things are set up and 
torn down.  That is left up to another part of the library to determine.

One such other part, OptimisingTestSuite, will look at *all* of your 
tests and find an order which involves the least redundant effort.

You might have something else that breaks up the test run across 
multiple processes and uses the resource declarations to run all tests 
requiring one thing in one process and all tests requiring another thing 
somewhere else.

You might have still something else that wants to completely randomize 
the order of tests, and sets up all the resources at the beginning and 
tears them down at the end.  Or you might need to be more 
memory/whatever conscious than that, and do each set up and tear down 
around each test.

The really nice thing here is that you're not constrained in how you 
group your tests into classes and modules by what resources you want to 
use in them.  You're free to group them by what they're logically 
testing, or in whatever other way you wish.

Jean-Paul
More information about the Python-Dev mailing list

RetroSearch is an open source project built by @garambo | Open a GitHub Issue

Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo

HTML: 3.2 | Encoding: UTF-8 | Version: 0.7.4