Art of Unit Testing

rafi 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

-- 
rafi

	"Imagination is more important than knowledge."
	                            (Albert Einstein)



More information about the Python-list mailing list