Test-first programming success story
I’ve heard people talk about test-first programming but in truth I had never really given it a good try. Until now.
Working on the e4 CSS support provided a great opportunity. As some of you may know, the e4 CSS code was generously contributed from an existing external project. Unfortunately, some of the IP lineage of the code was tainted with GPL code so some didn’t make it into the Eclipse CVS repository. This left a number of classes missing in the middle of the contribution.
I knew which classes were missing, including their hierarchies and implements, and I was able to generate the method signatures by either quick fixing calls to missing methods or by gen’ing the required interface methods. Now to fill in the method bodies.
A perfect opportunity for test-first programming!
I wrote a very basic junit test (create an SWT label, have style sheet set background color, check if that’s the color in the widget). I then went to every method with missing body and wrote:
throw new UnsupportedOperationException("NOT YET IMPLEMENTED");
I picked this because its a runtime exception and thus didn’t require changing method signatures or callers, and because I’d be unlikely to trigger one in some other code. I then set the Eclipse debugger to breakpoint on all caught and uncaught UnsupportedOperationException’s.
Development proceeded like:
- Run test
- See where it halts
- Write the method
- Rerun, repeat!
It was somewhat reminicient of the “laying the tracks out in front of the train” scene in Wallace and Gromit.
What was curious about this approach was that I was completely surprised (and delighted) when it finally ran green. I knew I was getting close based on the places where it was stopping, but still didn’t know how close!
I think the key here was that I had such a good specification of the requirements of the code and this could be easily translated into a test. The test was obvious to write, and the need for a test to guide my coding was also obvious — What else would I do, keep running the same example? Might as well write it as a test!
For more open ended problems the requirements and code sort of co-evolve. Maybe in this case test-first does apply as well, or then again maybe you use the tests as the way to express one side of the evolving contract.
In any case, this experience was an excellent example of how valuable an approach it can be.
Posted December 11th, 2008 by Kevin McGuire in category: Uncategorized
You can skip to the end and leave a response. Pinging is currently not allowed.
4 Responses to “Test-first programming success story”
Leave a Reply
You must be logged in using your Eclipse Bugzilla account to post a comment.
Ketan Says:
December 12th, 2008 at 1:27 am
Kevin,
I’d actually argue that this is not the correct way to TDD, unfortunately eclipse forces one to do this; implement a big interface and figure out gets called in what order. I’m happy to see that people trying to write tests for e4, but I wish this practice had come into the eclipse ecosystem earlier.
It is recommended to it the other way around — set up expectations for interactions (mocks/stubs) and assertions one at a time, and then write the implementation to make the test pass. This also ensures that the api is driven through tests and not the other way around, which is what you seem to be doing.
Andy Maleh Says:
December 12th, 2008 at 11:45 am
Good to hear you’ve had a good experience with test-first development.
It took me a while to get used to test-driven development, but once it became a habit (after a lot of practice) and I became fully convince of its benefits, I stopped trusting any code I write before writing tests first. When I feel the creative juices flowing and want to write code without tests, I do it as a spike, verify its small success, and then re-write it test-first.
Kevin McGuire Says:
December 12th, 2008 at 4:24 pm
@Ketan, you said,
> I’d actually argue that this is not the correct way to TDD
I think in my case it’s because I had a large body of known to be working code with pieces missing here and there due to IP issues. But I don’t know much about test-first so you may be right.
Ketan Says:
December 14th, 2008 at 5:02 am
Kevin,
TDD does not /always/ mean test-first development. Sarah puts this nicely on her blog[1] [2]. Also ensuring that we’re writing one test at a time helps [3] tremendously.
[1] - http://sarahtaraporewalla.com/thoughts/testing/tdd-does-not-mean-test-first/
[2] - http://sarahtaraporewalla.com/thoughts/testing/a-conversation-with-a-tdder/
[3] - http://www.markhneedham.com/blog/2008/12/09/tdd-one-test-at-a-time/