Hardware take on software testing.

[Michele Simionato]

Steven Taschuk <staschuk at telusplanet.net> wrote in message news:<mailman.1055258425.21148.python-list at python.org>...
> Fwiw, I agree entirely with your point that sometimes (rarely) TDD
> does not provide adequate coverage of cases.  What agile
> methodologies gain you in this case, imho, is practical experience
> with candidate algorithms and direct experience of the subtlety of
> the subject.  This is very valuable.

Indeed.

> Now that you have that experience, you might be motivated to throw
> away what you have and take a more formal approach: Formalization
> of the Python type system, formal characterization of the
> circumstances under which the metaclass/metatype conflict occurs,
> proof that such-and-such an algorithm avoids those circumstances,
> you know the drill.
> 
> Imho such methods are worth it in such cases.  (Type system
> hacking is one area where I *do* want proofs of correctness.)  But
> an important point: you would not know for certain that this was
> needed if you hadn't used agile methodologies to explore the
> domain in the first place.
> 

An interesting point.

> > In the same sense that one should be skeptical about the confidence he gets 
> > when the program compile, he should be skeptical about the confidence he gets 
> > when the program passes the test suite.
> 
> In the same sense, yes.  But to a much lesser degree, of course;
> the test suite is smarter than the compiler.

Of course, no doubt about it. I was somewhat bashing advocates of compiled
languages, when they say "the compiler guarantees me more safety than
the interpreter" whereas actually I think it guarantees an apparent safety. 
The safety from the tests is more than apparent, true, but still it is 
not absolute, how true believers in TDD would claim. This was my only
point.

                                      Michele