Art of Unit Testing
rafi at free.fr
Tue Aug 2 23:13:08 CEST 2005
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
"Imagination is more important than knowledge."
More information about the Python-list