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

Olemis Lang olemis at gmail.com
Wed Feb 10 22:27:43 CET 2010

On Wed, Feb 10, 2010 at 3:56 PM, R. David Murray <rdmurray at bitdance.com> wrote:

On Wed, 10 Feb 2010 09:45:41 -0500, Olemis Lang <olemis at gmail.com> wrote:

On Tue, Feb 9, 2010 at 5:34 PM, Holger Krekel <holger.krekel at gmail.com> wrote: > On Tue, Feb 9, 2010 at 10:57 PM, Ben Finney <ben+python at benfinney.id.au> wrote: >> Michael Foord <fuzzyman at voidspace.org.uk> writes: >> >>> The next 'big' change to unittest will (may?) be the introduction of >>> class and module level setUp and tearDown. This was discussed on >>> Python-ideas and Guido supported them. They can be useful but are also >>> very easy to abuse (too much shared state, monolithic test classes and >>> modules). Several authors of other Python testing frameworks spoke up >>> against them, but several users of test frameworks spoke up in >>> favour of them. ;-) >> >> I think the perceived need for these is from people trying to use the >> unittest API for test that are not unit tests. >>

Well the example I was talking about before is when some (critical) resource needed for unittesting requires a very, very heavy initialization process. I'll employ the most recent example (hope it doesn't look like too much biased, it's just to illustrate the whole picture ;o) which is unittests for a framework like Trac . In that case it is critical to have a Trac environment, a ready-to-use DB and backend, initialize the plugins cache by loading relevant plugins, run the actions specified by each IEnvironmentSetup participant, sometimes a ready to use repository (if testing code depending on Trac VCS API) and more ... Just considering these cases someone could : - Create a fake environment used as a stub - But having a single global environment is not a good idea because  it would be very difficult to run multiple (independent) tests  concurrently (e.g. test multiple Trac plugins concurrently in a dedica= ted  CI environment). So an environment has to be started for every  test run and be as isolated as possible from other similar  stub environments - The DB and backend can be replaced by using in-memory SQLite  connection - Plugins cache and loading is mandatory as well running the actions  specified by each IEnvironmentSetup participant - VCS can be mocked, but if it's needed it has to be initialized as well And all this is needed to run ANY test of ANY kind (that includes unittests ;o) . I hope that, up to this point, you all are convinced This doesn't sound very unit-testy, really.  It sounds like you are operating at a rather high level (closer to integration testing). As someone else said, I don't see anything wrong with using unittest as a basis for doing that myself, but I don't think your example is a clear example of wanting a setup and teardown that is executed once per TestCase for tests that are more obviously what everyone would consider "unit" tests.

Well, probably this is OT here but I follow in order to clarify what I am saying. I am not integrating talking about integration tests, but in general, yes they are unittests, but for Trac plugins (i.e. it is possible that others tests won't need all this ;o) . For example let's consider TracRpc plugin. Let's say you are gonna implement an RPC handler that retrieves the ticket summary provided it's ID (pretty simple method indeed) . In that case you need

Let's say you will only test that second part (which is the functional part without any objections ;o). In that case you'll still need a Trac environment, you'll need to setup the DB connection inside of it , and all that just to perform the query . In general, in such cases (e.g. DB access, but there are others ;o), almost everything needs a Trac environment and therefore, at least part of what I mentioned before

;o)

So, having the connection to the database set up once at TestCase start, and closed at TestCase end, would make the most sense.  Currently there's no way I know of to do that, so I open and close the database for every unittest.  Fortunately it's an sqlite database, so the run time penalty for doing that isn't prohibitive.

I really cannot see the difference between this and what I mentioned before since one of the things that's needed is to create a connexion just once for each test run, but (guess-what !) the connection needs to be set for the environment itself (i.e. trac.env.db ) so first the chicken, then the egg ;o)

PS: BTW, The situation you mention is almost the classic example ;o)

-- Regards,

Olemis.

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

Featured article: PEP 391 - Please Vote! - http://feedproxy.google.com/r/TracGViz-full/3/hY2h6ZSAFRE/110617

More information about the Python-Dev mailing list