opening it up with Common Lisp

Favorite weblogs

Lisp Related

Bill Clementson

Finding Lisp

Lemonodor

Lispmeister.com

Planet Lisp

Politics

Orcinus

Talking Points Memo

This Modern World

Working for Change

Other home

Polliblog

Recent Readings

Book review: Darwinia
Reviewed: Friday, August 11, 2006

Summer reading: Spin
Reviewed: Saturday, August 5, 2006

Runner
Reviewed: Tuesday, July 18, 2006

the Omnivoire's Delimma
Reviewed: Wednesday, July 12, 2006

the Golem's Eye
Reviewed: Wednesday, May 31, 2006





tinderbox
 width=

The test-first mantra
Wednesday, June 9, 2004

Like Tim Bray (and many others!), I'm a fan of test driven development. I even wrote and documented one for Lisp in January of 2001 (my first non-trivial macro). Unlike many others, however, I've never been test-infected. In spite of good intentions, I generally honor testing more in theory than in the breach. Odes to testing like Bray's leave me feeling both somewhat sullied, yet curiously inspired to try again. First, some thoughts on why testing for Lisp is different that testing for Java or C#.

  • Lisp is interactive: Lisp is so test/code friendly that it's too easy to test directly in the Listener and only in the Listener. You can't do that in Java -- you have to write code. I've found that even very slight impediments are enough to prevent me (and, I think, most other people) from doing what's right. If there is nothing else that American culture teaches it's that "easy" is far more popular that "correct".
  • Lisp is functional: True functional code is side-effect free and comes close to the dream of provable correctness. If you have functional code and you've tested it in the listener, you probably don't need to test it again -- not at the unit level in any case.
  • Lisp is language design: Large Lisp systems almost always involve building languages that express the problem domain. This is so much beyond modeling a domain with classes that I don't think people can get it without actually doing it themselves. One can test the parsing and expansion plumbing of this work but not the designs themselves. Furthermore, testing macros is tricky (you have to deal with expansions and with read, load and compile time behavior).
  • Finally, there is an echo in here. Lisp is interactive: the test system you use has to be a part of the language and of the IDE you use otherwise it just won't fit. The initial design of LIFT was a pretty straight port of the ideas in SUnit but the first redesign worked hard to make LIFT feel like Lisp. This isn't easy and there is still lots of room for improvement.

Though I seldom have the time I wish for it, I like building tools (like this one). Programming is an immense, boulder strewn path which we must navigate and every little smoothed patch of ground is a win. Tools smooth the ground. I think that there is lots of room for innovation and new ideas for testing within and for Lisp. More to follow...


|

Home | About | Quotes | Recent | Archives

Copyright -- Gary Warren King, 2004 - 2006