«

Quoth Manish Jethani:
[...]
> Actually I am writing a client app for a proprietary service.
> The server is not under my control, so I can't make it behave in
> a way that will cause every part of my client code to be tested.
> As I mentioned, for example, I have a function to handle a
> server-disconnect. But the server rarely ever disconnects of
> its own, so the function never gets called in reality. Can I
> unit test this function easily?

Mock objects are the usual approach to this kind of problem.
(Google can tell you more.)

--
Steven Taschuk
Receive them ignorant; dispatch them confused. (Weschler's Teaching Motto)

Make it a policy that your unit test suite has 100%
statement coverage at all times. Then this
particular thing won't happen.

How do you do this without impacting your
development? Try Test Driven Development.
If you do it *properly*, you'll get close to
100% statement coverage without any extra
effort.

John Roth

"Manish Jethani" <> wrote in message
news:ZPaUa.6$...
> Hi all,
>
> Is there a way to detect typos in a Python program, before
> actually having to run it. Let's say I have a function like this:
>
> def server_closed_connection():
> session.abost()
>
> Here, abort() is actually misspelt. The only time my program
> follows this path is when the server disconnects from its
> end--and that's like once in 100 sessions. So sometimes I
> release the program, people start using it, and then someone
> reports this typo after 4-5 days of the release (though it's
> trivial to fix manually at the user's end, or I can give a patch).
>
> How can we detect these kinds of errors at development time?
> It's not practical for me to have a test script that can make
> the program go through all (most) the possible code paths.
>
> -Manish
>
> --
> Manish Jethani (manish.j at gmx.net)
> phone (work) +91-80-51073488
>
>

John J. Lee wrote:

> Manish Jethani <> writes:
> [...]
>
>>>The proposed typo catcher would probably catch a typo like
>>>
>>> sys.edit (5) # finger didn't get off home row
>>>
>>>but it probably would *NOT* catch
>>>
>>> sys.exit (56) # wide finger mashed two keys
>>
>>1) That's in a different class of typos. Such things can't be
>>auto-detected in any language. It will probably require close
>>examination by the human who wrote it in the first place, or
>>someone who has been debugging it.
>
>
> That was, indeed, precisely the point that was being made. Tests can
> catch these, static type analysis can't.

There's a difference between my "abost()" example and the "56"
example. There's no function called abost anywhere in the
program text, so I should be able to detect the error with
static analysis. Even in C, the compiler warns about stray
function calls.

The "56" example is out of place here. I have fixed the code:

--------
[maybe a constants.py or whatever]
arbit_code = 56

[... elsewhere...]

sys.exit(arbir_code)
--------

That error can be caught in static analysis.

>>2) No on calls sys.exit() like that. 5, or 56, is probably a
>>constant defined somewhere (where such typos are easier to spot).
>
>
> Yes. Do you have a point?

Yes. Don't use bad coding practices as an excuse.

-Manish

--
Manish Jethani (manish.j at gmx.net)
phone (work) +91-80-51073488

Manish Jethani wrote:
>
> There's a difference between my "abost()" example and the "56"
> example. There's no function called abost anywhere in the
> program text, so I should be able to detect the error with
> static analysis. Even in C, the compiler warns about stray
> function calls.

You don't understand the dynamic nature of Python if you
think this is something that is either easy or 100% reliable.

Very contrived but instructive example:

def func(x):
pass

import sys
setattr(sys, 'ab' + 'ost', func)

stick-that-in-your-static-analyzer-and-smoke-it-ly y'rs
-Peter

>>>>> "Peter" == Peter Hansen <> writes:

> You don't understand the dynamic nature of Python if you
> think this is something that is either easy or 100% reliable.

> Very contrived but instructive example:

> def func(x):
> pass

> import sys
> setattr(sys, 'ab' + 'ost', func)

> stick-that-in-your-static-analyzer-and-smoke-it-ly y'rs

The dynamic nature of Python is definitely a problem but there are some
obvious workarounds. For example a static analyzer can take an option that
says "assume standard modules are not modified". This is probably good
enough for 90% of the cases.

Ganesan

--
Ganesan R

Manish Jethani <> writes:

> There's a difference between my "abost()" example and the "56"
> example. There's no function called abost anywhere in the
> program text, so I should be able to detect the error with
> static analysis. Even in C, the compiler warns about stray
> function calls.

But in your example, you were calling "session.abost". Due to
Python's dynamic nature, there's no way for a static compile-time
analysis to know for sure if the object to which session (I'm guessing
it's a global from the code) refers _at the point when that code
executes_ has an abost method or not. Or rather, no way I can see
other than having the compiler actually execute the code to determine
that fact.

Given that you want some specific behavior to occur on a close
connection event, you're really best served by having a test that
actually simulates such an event to verify that your action occurs.
That's true in any language, although particularly so in Python. It's
certainly best to use automated tests, but even some manual setup for
more complicated network situations can help. For example, if I were
writing such a system, I'd probably at least manually start up a
modified server that explicitly disconnected more frequently so I
could exercise that aspect of tear-down more easily. Otherwise
(syntax checks or no), I'd be releasing code without really having any
idea that it would do the right thing in such a teardown situation.

Think of it just as another aspect to "good coding practices".

-- David