[TIP] Testing for wrong type errors

Chris Lasher chris.lasher at gmail.com
Mon Nov 12 17:14:43 PST 2007

On Nov 12, 2007 11:44 AM, Michael Schlenker <msc at contact.de> wrote:
> The more exposed to direct user input the code is, the more rigid the checks
> usually get. If the function faces the 'outside world' e.g. websites, the checks
> get draconic to minimize security issues (like revealing tracebacks thrown into
> the face of a user, code injection or other nasty stuff).

I like to follow a similar gradient of rigidness. The closer to user-
or file-based input, the more checks I erect to protect the program
from horking late down the logic paths, or worse, not horking at all
and simply giving non-sensical (or worse, unreliable and "believable")
results. That said, isinstance() and bounds checks get scattered
pretty liberally throughout the program, and I do write unit tests
that throw garbage at functions/methods to make sure they raise a
ValueError (my exception of choice--I think it makes the most sense)
when given bogus input. These tests are usually the easiest to write.

I do notice I rarely write checks for the output data--I rely on unit
tests to make sure that "looks" the way it should.


More information about the testing-in-python mailing list