dynamic typing questions

[John Roth]

"Alexander Schmolck" <a.schmolck at gmx.net> wrote in message
news:yfs7k0qthzg.fsf at black132.ex.ac.uk...
> "John Roth" <newsgroups at jhrothjr.com> writes:
>
> > "Alexander Schmolck" <a.schmolck at gmx.net> wrote in message
> > news:yfsu13viaf2.fsf at black132.ex.ac.uk...
>
> When a test fails (assuming I'm running emacs/ipython with ``@pdb on``)
this
> will automatically visit the file and line where the test fails in emacs
and
> throw me into the debugger in ipython so that I can easily see *why* the
test
> fails (by examinging the local variables, typing in expressions to try out
> things, going up and down the stack (which will automatically visit the
right
> files and locations in emacs) etc.).
>
> I find that this makes any development of tests (whether ''test-driven''
or
> not) much more pleasant and the development of tests that contain loops
and/or
> complex/random state bearable.
>
> If you think that you develop your tests more effectively by not using
> something like the above, I'd be really curious to hear details.

All I can say is that I use what I presume is the now-standard TDD
methodology: take real small steps so that there is no question about
what code caused the problem, and keep the code so simple that
it's not generally a problem to figure out what happened if a test does
fail.

The dogma is that if you're writing more than a dozen lines (and five
or six is average) for a failing test, then you're moving in steps that
are way too big. When I take bigger steps, I find I pay for it.
The time spent debugging is definitely super-linear in the number of
lines written between runs of the test suite.

And of course it's wise to keep your eye on the code coverage
metric.

John Roth
>
>
> 'as
>