[Python-Dev] setUpClass and setUpModule in unittest

[Olemis Lang]

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

  - Implement IRPCHandler interface (in order to extend RPC system ;o)
  - Query ticket data

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