Jon Udell is investigating Test-First (aka Test-Driven) Programming...
Test-first is quite radically different from test-later. And the most important difference I've discovered so far is that test-first... is as much a tool... exploration of the problem domain... as it is a way of protecting against regression.
You've got it Jon. I think of it this way...
Test-driven design tools are "command line interpreters" for Java, C#, and other "non-interactive" programming languages.
Programmers using Lisp, Smalltalk, APL, and other "interpreted" languages have been doing test-driven design for decades. The pattern here is to type little snippets of code for an idea, get immediate feedback, then gradually incorporate those snippets into a whole program.
Lisp has its read-eval-print loop. So does Python. Smalltalk traditionally has "workspaces" which are text editors that also evaluate highlighted code.
In either case, the end of a programming episode results in a transcript of code that is then allocated to two destinations... some of the code in the transcript are the objects or functions that go into the program itself. The rest of the code is edited into regression tests.
Looking at a test-driven incremental programming session using junit or nunit you see the very same result... the shell is the command line and xUnit is the "interpreter". You get a small idea, test it, and repeat.
The tests themselves are the "transcript" of the session, and are also the preserved regression tests.
This approach is so successful that it provides discipline for Lisp and Smalltalk programmers too. I think Kent Beck originated sunit (for Smalltalk) as a way to demonstrate to new Smalltalk programmers how to use workspaces effectively.
1 comment:
Thanks, that's a missing piece for me. I almost had that a couple of years ago, but you've made it click.
Post a Comment