« Map/Reduce in the Micro | Main | The Carrying-Cost of Code: Taking Lean Seriously »

April 14, 2011



Darius Bacon's Halp is like this - literate programming with embedded exploratory tests.


Carl Friedrich Bolz

The Python module doctest is exactly for that. You paste console sessions into files (or docstrings) and then you can execute them as tests:


Michael Feathers

@johnnicholas Thanks!

@Carl Freidrich Bolz Yes, it seems docttest is close, but not quite the same. You're looking a transcript rather than test code.


It's been a while since I used Eclipse, but it seems that you get exactly the effect by writing unit tests before you write the code.

Writing SQL views I use a sort of progressive refinement that has a similar 'smell.'

With scripts I often set up a shell loop with a marker file, e.g.

while true
if [ \! -e .marker.file -o scriptundertest.sh -nt .marker.file ]
touch .marker.file
sleep 1
date +'%Y-%m-%s %H:%M:%S - no changes to script'
sleep 15

The key thing is that your tests need to be idempotent or otherwise harmless while still giving you the info you need.

William Pietri

Very interesting point!

Couldn't one go the other direction and turn tests into something more REPL-like?

I'll often have either a test class or a single test called Scratch. Perhaps we could create a special test runner that runs continuously and, for whatever test you last changed, produces extra output. E.g., it shows the current test code plus annotations with interesting result values.


You may have hit on an explanation for why APL people said "We've been doing this TDD stuff for _years._"

iPhone contacts backup

That's amazing.

cheap designer handbags

183 ve read through a number of the articles in your website , and I love the way you blog. I included it to my favorites blog site list and will also be checking quickly. http://www.viphandbagscheap.com

The comments to this entry are closed.