TDE - test-driven exploration
So I was geeking out last night, as Mike would say. I was writing some code to fix some corruption in my calendar. It's in iCalendar format, so I found an ical4j framework on SourceForge and fired up Eclipse.
The first thing I did was to copy some snippets of sample code from the ical4j docs into a JUnit test and see what happens. I did this for 2 reasons: (a) the docs for FOSS are often wrong, and (ii) I needed to get all the config set up (e.g. to make a test calendar with events in it containing the properties I was interested in.)
As I worked, my "production code" kept evolving inside my test class. When I had successfully TDD'ed a step, I extracted the code into a real production class. I could move code around with Eclipse's refactoring tools and I had solid tests to save my butt.
Nothing startling in any of this. The interesting thing for me was that I was
exploring ical4j. It was something of a spike - I didn't know ahead of time if the framework would be up to the job - yet each success immediately resulted in moving the code to the production classes.
So what do you think of this approach of evolving the code in the test and moving it as soon as it's green?
Redux: Keith Ray says: It's good. I think Kent Beck or someone called these "Learning Tests"when learning an API via TDD.
Labels: java, xp
Comments:
