Python vs .Net

[Peter Hansen]

Greg Brunet wrote:
> 
> "Peter Hansen" <peter at engcorp.com> wrote in message
> > write LOTS of unit tests, and acceptance tests, to catch these
> > problems before you release.  But you do that anyway (right? ;-) )
> > since the minimal checking your VB.NET compiler does cannot possibly
> > catch the majority of problems in your code...
> 
> [...]  I don't see the need to
> increase the amount these tests in order to catch stuff that the
> compiler can otherwise find for me (when statically typed).  Also, I (1)
> wonder how many folks really do this to the necessary degree in the all
> of their apps (I haven't seen this kind or degree in test code in the
> Python code that I've reviewed so far, 

Definitely not everyone does it (yet?).  On the other hand, some people
*are* doing it.  For one thing, much or most of Python's own code has
extensive unit tests (check out the /lib/test folder).  As another good
example, the Twisted framework was developed using XP and has unit tests
using the PyUnit test framework.  See http://twistedmatrix.com/ for more.

The fact that few are doing this doesn't invalidate the concept.  It just
means that many have ignored good advice for decades.  The emergence of 
the new "agile" development methods means that more are being exposed
to the benefits for the first time, and in a context which makes it 
much more likely they will actually be able to build such tests.

> and (2) unit testing something
> for different conditions DOES NOT relieve you of the need to add error
> checking code, and I have seen virtually none of the error checking code
> I would expect in the stuff I've reviewed.  Does all your code check to
> make sure that you are passed an integer instead of a float or a string?

Actually, in many cases it *does* relieve you of the need for error 
checking code.  I likely wouldn't convince you of this in a short post,
but there are books being written on the subject as we speak... 

The fact that all the important paths in my code are exercised before
I release means that I don't need to worry about explicit tests for
integers versus strings or floats.  My tests give me confidence that
the function that cares about this is *not* called with bad values.

I also know a number of other things about it that your VB compiler
cannot possibly tell you.  I know that the logic contained in that 
function actually works.  I know that the value passed in, not the 
constant that I hacked in during debugging and forgot to remove later,
is actually the one used.  I know that the subroutines called by
that function are correct as well, and that I didn't use the wrong
name for something during a cut-and-paste accident.  How would VB
tell you all that without tests?

I think any discussion which compares Python unfavourably with 
a statically typed language where the compiler can do type-checking,
but which does not assume full unit testing will be performed, is
merely a way of justifying code-and-fix hacking in the statically
typed language.  If you assume proper testing, the advantages of
the statically typed language are vastly diminished.

-Peter