Testing dynamic languages

[Francesco Bochicchio]

On Sat, 04 Apr 2009 07:37:44 -0700, grkuntzmd wrote:

> I am a Java developer. There, I said it :-).
> 
> When I am writing code, I can  rely on the compiler to confirm that
> any methods I write will be called with parameters of the "right"
> type. I do not need to test that parameter #1 really is a String
> before I call some method on it that only works on Strings.
> 
> If I am writing in Python, since it is dynamically, but strongly
> typed, I really should check that each parameter is of the expected
> type, or at least can respond to the method I plan on calling ("duck"
> typing). Every call should be wrapped in a try/except statement to
> prevent the method (and program) from crashing when my method is
> called with an integer instead of the expected string.
> 
> Is this the experience that Python programmer (of large projects) see?
> Do you also write unit tests to confirm that the methods actually
> check for and catch "bad" parameter types? If I am writing small one-
> off scripts, I wouldn't worry about it, but if I am writing a large
> system that must have 99+% uptime without constant monitoring, this
> really should be verified.
> 
> Up for discussion...

Uhm. 
I write large bodies of code for living ... not in Python, unfortunately.
I usually divide my code in two classes wrt sanity checks : inner code and
boundary code. Boundary code gets paranoic checks on everything:
arguments, consistency etc ... also with static typing : an 'int'
parameter declaration in C/C++ make sure that your function gets an
integer, but ensure nothing in the way of minimum and maximum value, so
before using it - say - as an array index, it is better to check
that. Inner code gets less checks, based on the assumptions that inputs
have been properly checked by the boundary functions.

This method is not without risks - an architectural change can move a 
function from an inner zone to a boundary zone, and I may forget to
'fortify' the function. However, this is a guideline that served me well.

Beside that there is another guideline I apply to languages like java and
python - programs in these languages do not 'crash' ... they throw
exceptions. Now, supposing to add an input check  : what are you
going to do if you find bad data? In the answer is - as often the case -
throw an exception, then maybe the check is not worth much ...

There are exceptions to this guideline, as always, like if you want to
generate a more meaningful exception, but this is another guideline I
tend to follow. And this means that my level of checking in python is 
much lower than in - say - C++. And I don't worry too much about argument
types, more about external inputs with the right 'semantic'.

The one coding behaviour that dynamic types forced me to change, is that
now I tend to build programs more incrementally, because catching typos
error and logic errors at the same time on a large body of code can be
frustrating and not very productive ... but I find myself to use now the
same approach also when I code in statically typed languages : a bit
slower at beginning, but tend to procuce more reliable results .

Ciao
----
FB