Project organization and import

[Alex Martelli]

Bruno Desthuilliers <bdesth.quelquechose at free.quelquepart.fr> wrote:

> >>I don't reload...  When my investigative tests gets bigger I write a script
> >>and run it with the interpreter.  It is easy since my text editor can call
> >>Python on a buffer (I use Emacs).
> >  
> > That's interesting, is this workflow pretty universal in the Python
> > world?
> 
> I don't know, but that's also mostly how I do work.

My favorite way of working: add a test (or a limited set of tests) for
the new or changed feature, run it, check that it fails, change the
code, rerun the test, check that the test now runs, rerun all tests to
see that nothing broke, add and run more tests to make sure the new code
is excellently covered, rinse, repeat.  Occasionally, to ensure the code
stays clean, stop to refactor, rerunning tests as I go.

I'm also keen on bigger tests (integration tests, as well as system
tests for regressions, acceptance, etc), but of course I don't run those
anywhere as frequently (they're not part of my daily workflow, iterated
multiple times per day -- more like a "nightly run" kind of thing, or
for special occasions such as just before committing into HEAD... I'm
somewhat of a stickler about HEAD *always* passing *all* tests...).

Not exactly TDD, please note -- I tend to start the cycle with a few
tests (not strictly just one), implement some large chunk of the
new/changed stuff, and add "coverage" and "boundary cases" tests towards
the end of the cycle (more often than not I don't need further changes
to satisfy the coverage and boundary-case tests, because of the "large
chunk" thing).  So, a TDD purist would blast me for heresy.

Nevertheless, having tried everything from pure TDD to papertrail-heavy
waterfall (including the "toss the bits over the wall to QA", shudder!)
to typical Chaos Driven Development, in over a quarter century of
experience, this almost-TDD is what works best for me -- in Python, C,
and C++, at least (it's been a long time, if ever, since I did enough
production Java, Haskell, Ruby, SML, assembly, Perl, bash, Fortran,
Cobol, Objective C, Tcl, awk, Scheme, PL/I, Rexx, Forth, Pascal,
Modula-2, or Basic, to be sure that the same approach would work well in
each of these cases, though I have no reason to think otherwise).


Alex