On Wed, Feb 10, 2010 at 3:56 PM, R. David Murray <rdmur...@bitdance.com> wrote: > On Wed, 10 Feb 2010 09:45:41 -0500, Olemis Lang <ole...@gmail.com> wrote: >> On Tue, Feb 9, 2010 at 5:34 PM, Holger Krekel <holger.kre...@gmail.com> >> wrote: >> > On Tue, Feb 9, 2010 at 10:57 PM, Ben Finney <ben+pyt...@benfinney.id.au> >> > wrote: >> >> Michael Foord <fuzzy...@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 _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
