Art of Unit Testing
gustav at morpheus.demon.co.uk
Sat Aug 18 14:19:04 CEST 2001
On Fri, 17 Aug 2001 11:32:49 -0700, Jeff Shannon <jeff at ccvcorp.com> wrote:
>Well, the alternative argument could be that, if you don't need to setup and
>teardown in between various tests, then they could be coded as subtests of a
>single, larger test... OTOH, if you *do* have high setup/teardown overhead, which
>*does* require being redone for each test, then coding it each time would be a
>pain. Lumping subtests together is easier than multiple copies of
I'm not sure I agree. The long and short of it is that both cases can happen.
But look at my example "for real" (sort of)
# May take seconds to execute...
self.connection = DB.Connect(connect_str)
def exec_query(self, q):
"Trivial helper to run a query"
q = "select 1 from dual"
"Exception when no rows returned"
q = "select 1 from dual where 1=0"
# And 100 more trivial queries...
You get the idea. The setup costs a *lot* in relative terms of time (each test
query takes, say, 0.01 second). You really want to only do that once. But you
don't really want to code a single huge test - it destroys the reporting of the
individual test docstrings by unittest.main(). What do you do? I don't say it's
not possible to code this - just that the documentation doesn't make it clear
Remember, I'm arguing that the common cases should be simple to code - not that
it's not possible to do these things. That makes people more likely to code unit
So really, I'm suggesting two things - (1) beef up the documentation of
unittest.main(), and give it a section to itself ("How to code a simple series
of unit tests"), and (2) if necessary, beef up unittest.main() to cater for such
common cases (I don't necessarily think this is required).
More information about the Python-list