Exhaustive Unit Testing

Roel Schroeven rschroev_nospam_ml at fastmail.fm
Sat Nov 29 11:36:56 CET 2008

Fuzzyman schreef:
> By the way, to reduce the number of independent code paths you need to
> test you can use mocking. You only need to test the logic inside the
> methods you create (testing behaviour), and not every possible
> combination of paths.

I don't understand that. This is part of something I've never understood 
about unit testing, and each time I try to apply unit testing I bump up 
against, and don't know how to resolve. I find it also difficult to 
explain exactly what I mean.

Suppose I need to write method spam() that turns out to be somewhat 
complex, like the class method Emanuele was talking about. When I try to 
write test_spam() before the method, I have no way to know that I'm 
going to need so many code paths, and that I'm going to split the code 
out into a number of other functions spam_ham(), spam_eggs(), etc.

So whatever happens, I still have to test spam(), however many codepaths 
it contains? Even if it only contains a few lines with fors and ifs and 
calls to the other functions, it still needs to be tested? Or not? From 
a number of postings in this thread a get the impression (though that 
might be an incorrect interpretation) that many people are content to 
only test the various helper functions, and not the spam() itself. You 
say you don't have to test every possible combination of paths, but how 
thorough is your test suite if you have untested code paths?

A related matter (at least in my mind) is this: after I've written 
test_spam() but before spam() is correctly working, I find out that I 
need to write spam_ham() and spam_eggs(), so I need test_spam_ham() and 
test_spam_eggs(). That means that I can never have a green light while 
coding test_spam_ham() and test_stam_eggs(), since test_spam() will 
fail. That feels wrong. And this is a simple case; I've seen cases where 
I've created various new classes in order to write one new function. 
Maybe I shouldn't care so much about the failing unit test? Or perhaps I 
should turn test_spam() of while testing test_spam_ham() and 

I've read "test-driven development" by David Astels, but somehow it 
seems that the issues I encounter in practice don't come up in his examples.

The saddest aspect of life right now is that science gathers knowledge
faster than society gathers wisdom.
   -- Isaac Asimov

Roel Schroeven

More information about the Python-list mailing list