[TIP] Isolated unit testing

Gary Bernhardt gary.bernhardt at gmail.com
Wed Feb 24 15:54:44 PST 2010


In my TiP BOF lightning talk, I advocated fully isolated unit tests
(tests that execute against only one production class, with no other
code executed). Here are some additional comments on that:

First, I want to clarify that I didn't mean to advocate isolated unit
tests as a standalone testing strategy. When I showed 500ish dots
flying across the screen in one second, that was one of seven test
suites from that project. The other six suites were various
integration, system, or functional tests. I strive to minimize
integration tests, but I still find it essential to have some at the
full-stack and subsystem levels, as well as for non-functional
requirements like performance.

What I was attempting to advocate (clumsily) is using isolated unit
tests for establishing basic correctness – "this piece of code does
what it claims to do" – as well as for driving design by making
complex object interactions painfully visible. The statement that
"these classes work together successfully", or "this product does what
business wants it to do" require some additional types of test suites,
at least for now. ;)

Finally, I mentioned J. B. Rainsberger's blog post and talk
"Integration Tests Are A Scam", both of which I highly recommend. You
can find the short blog post at [1], and the talk video at [2]. On a
related note, I also highly recommend his blog post "How test-driven
development works (and more!)" [3]. Actually, you should probably read
that one first! :)

[1] http://www.jbrains.ca/permalink/239
[2] http://www.infoq.com/news/2009/04/jbrains-integration-test-scam
[3] http://www.jbrains.ca/permalink/285

-- 
Gary
http://blog.extracheese.org



More information about the testing-in-python mailing list