Testing dynamic languages

G

grkuntzmd

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...
 
E

Emmanuel Surleau

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.

Well, it depends on what you're trying to do, really. You do *not* want to
check parameters in every function. If you are designing a library, it is
strongly advised to document what kind of parameters your functions
expect. Otherwise, if your program will handle arbitrary input, you should
check its format and reject it if it's invalid.

Cheers,

Emm
 
T

Tim Wintle

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.

At some point you should wrap it in a try/except block - but only at the
point where you want the exception to be handled. That will normally be
quite far up, and you'll just let the exception travel back up to that
point.


for example, in a web server type of thing you might have something
vaguely like


def main:
for request in request_itter:
try:
headers = request.get_headers()
dispatch = get_dispatch_fn(headers)
response = dispatch(response)
except:
send_500()

You probably then don't need to catch any exceptions in the get_headers,
or actual processing methods (unless you are writing to sql or
something, when you might want to wrap all statements in a try block,
and then put a "ROLLBACK;" query in the except block (and then raise the
caught exception so it goes back the the block above)
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.

I write large applications with a target of 99.9% uptime, and I don't
find it a problem. occasionally I have to check parameters, but that's
not very often
 
G

grkuntzmd

This may be obvious but, clearly there are (at least) two general
types of errors: those caused by data external to the program and
those caused by bugs in the program. For all inputs coming into the
program from outside, such as user inputs and data coming over a
network, the inputs must be completely checked -- always assume that
they will be incorrect and are intended to crash your code -- be
pleasantly surprised when they are not :). Check for all bad inputs.

If the data are from inside the program, the assumption may be that
they are good and if not, it was a bug. I suppose you can write unit
tests on each routine to see that the methods that routine calls are
with valid arguments (using mocks). I actually tried this in a Java
program using JMockit; it was tedious, but it did catch a few
"potential" bugs. I would love to say that I ALWAYS remember the input
and output condition of every subroutine I write, but I just finished
a new feature for a company project that involved 100+ routines and
classes and I admit that I don't always remember which ones can return
null and which always return empty arrays, for example, even though I
try to write JavaDocs at the top of each routine. By mocking these
routines, I can check that the caller always handles each case
gracefully.
 
B

bearophileHUGS

grkunt...:
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.

Others have already given you most of the answers (summary: don't do
that. Don't fight the language. Use doctests). My other suggestion is
to read code coming from 5+ Python programs written by other
(different) people. You will see how to use Python.

Bye,
bearophile
 
B

barisa

that. Don't fight the language. Use doctests). My other suggestion is
to read code coming from 5+ Python programs written by other
(different) people. You will see how to use Python.

Bye,
bearophile

Is there some online repository for such code?
:)

Regards
Begginer
 
N

Nick Stinemates

Plenty. Try github.com for starters.

-----Original Message-----
From: [email protected]
[mailto:p[email protected]] On Behalf Of
barisa
Sent: Sunday, April 05, 2009 10:22 AM
To: (e-mail address removed)
Subject: Re: Testing dynamic languages

that. Don't fight the language. Use doctests). My other suggestion is
to read code coming from 5+ Python programs written by other
(different) people. You will see how to use Python.

Bye,
bearophile

Is there some online repository for such code?
:)

Regards
Begginer
 
A

Aahz

Is there some online repository for such code?

Start with Lib/ in the source ;-)
--
Aahz ([email protected]) <*> http://www.pythoncraft.com/

"...string iteration isn't about treating strings as sequences of strings,
it's about treating strings as sequences of characters. The fact that
characters are also strings is the reason we have problems, but characters
are strings for other good reasons." --Aahz
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,744
Messages
2,569,483
Members
44,903
Latest member
orderPeak8CBDGummies

Latest Threads

Top