Efficient python programming...

[Peter Hansen]

Sean 'Shaleh' Perry wrote:
> 
> > I disagree, if the tests are written first (and run, proving that
> > they will fail when the code is wrong or missing).
> >
> > The tests are executable requirement specifications.  Running
> > them "proves" (yes, not 100%... nothing could) that the code
> > meets the specs.  The specs could be wrong of course, but that
> > doesn't mean the code is broken...
> 
> this also assumes the test covers every possible failure.  this also assumes
> one can write tests for that section of code.

And all these sorts of things are the direct focus of test-driven
development.  For example, on the issue of testability: code developed
this way is inherently testable because the test was written first,
and the code had to be written to pass the test.  Code developed in
a more traditional way is much less likely to be testable and often
ends up tightly coupled and very hard to test or maintain as a result.
This, of course, tends to lead to having no tests at all, which is
a terrible thing.

I guess I was just taking a moment to point out there are some new
approaches which are more useful than the traditional (and generally
neglected) approach of writing a handful of tests after the fact.

I was also rebelling momentarily against the idea of shipping code
to a customer without having a suite of unit tests in place to give
confidence in the code.

I'll step back from any claim that unit tests really prove anything,
but in a very Pythonic and pragmatic fashion they are Good Enough to 
make them a /necessity/ for anyone trying to deliver reliable software.

-Peter