Christoph Zwerschke wrote: > Björn Lindström wrote: > > I already gave the example of creating database connections > or even creating/importing whole databases. My question was, how do I > handle these cases with the standard lib unittest?
I do not get why a unit test whould create/import a whole database. In order to unit test a function / method one should use mock objects, otherwise you may not be sure that your code is faulty. A mock object is an object that let the object uder test think it is connected to a database, but it is not really connected to one. This object is programmed to return well know values (correct, incorrect and exceptional ones). What you are talking about is more related to interaction / load tests and not unit tests (at least to me who am not an expert of unit testing). > According to the "extreme programming" paradigm, testing should be done > several times a day. So a requirement for extreme programm is that tests > are fast enough. If the testing needs too much time, people are > discouraged to test often. Well as I said above, a unit test is dedicated to a single function or method. So wehn you update a function / method, you should test the whole class or module, but maybe not the whole application (or the development task may have not been properly organized --splited between several developers). As someones may not write several thousand lines a day, unit tests should not be that long to run (well from my point of view, which is again not the one of an expert of unit testing). I do agree with Benjamin Niermann when he says: "Or because it is already close to perfection (at least in what it is intended to do)." unittest is for unittesting :-) my 2 cents -- rafi "Imagination is more important than knowledge." (Albert Einstein) -- http://mail.python.org/mailman/listinfo/python-list