TDD (Test-Driven Development)

web.adds/sw.dev.process 
/TDD (Test-Driven Development):
7.1:
"( my python web app is obs ! )
"( you forgot your TDD unit tests, pal )
. what is TDD?  Test-Driven Development
TDD != Unit Testing Dave Rolsky 2009
7.5: synth:
. in test driven development,
rather than ask "(how to impl this feature?),
we ask "(how do you prove
that a feature is impl'd?)
-- and that drives your interface design
(ie, the tests are designed even before
the interfaces, not just the bodies).
links:
sw.dev.process @ wiki
Xunit options for obj'c

agilepainrelief.com:

 I’ve been on projects where we tried to write
all of our tests after the classes were written.
Our test suite was valuable
 and prevented many regressions.
But it allowed many issues to slip through.
Weaker elements in API’s were often missed
and were changed only at a later date
at some expense.
Tightly coupled code was allowed to evolve
making some elements of the application
very difficult to test
without having to create dozens of
other (often unnecessary) objects.
As a result of all this
it became more difficult to write test cases over time.
Would TDD have solved all of these problems?
Perhaps not but it would have forced us to
confront many of them sooner.  

unit testing vs Test-driven_development
. the unit test tries to verify
all features of a given module;
 tdd (Test-driven development) is about
using tests as documentation:
. assuming you already have
libraries of utilities and datatypes,
you design the interface first
then the tests, and finally the bodies
that will make the tests pass .
. if you are writing your documentation first;
then you won't have any problems with also
writing test harnesses before the app is built .

. this is supposed to complement prototyping:
the developer often needs a semi-working model
to get ideas for a more polished model .
. the prototype is then used as the basis
for a high-reliability app
that writes the final design as a set of
user doc's, unit tests,
maint'doc's, feature tests,
and functional tests (having each function
beginning with precondition testing
and ending with postcondition testing).

. reverting to the last version that passed all tests
may often be more productive than debugging.

instead of relying on platform services directly,
they should be accessed through a wrapper,
so that functional testing can be applied .
--
See dependency inversion principle