Ketan's Musings

This is in continuation to my previous post “Eclipse and TDD”

I feel that the question that I posted “Given this scenario, how do you do test-first-development ?” needs some clarification:

There’s one interface that needs to be implemented to accomplish a certain task. This one interface is supposed to return some more interfaces. Also you’ve never used those interfaces before, makes things unpredictable in some sense. You therefore end up taking small steps, try out a few things here and there, see what happens as you go along, and your implementations evolve quickly over the period of a few minutes. By which time your implementation is complete, and you have not written a single line of test

You then quickly get to refactor the code that you’ve written to make it “testable”. This code was never written with “testablity” in mind in the first place, so it will never be testable in a way that you really want it to be.

The problem to me seems to be the fact that the “expectations” from the interface are not known before the tests are written.

So does this mean that:

• I need to better understand the interface before I start using it ? Read the JavaDocs, other implementations that do something “similar” ?
• Assuming that I do understand (to some certain extent) what the intent of the interface is, and I go ahead and implement that interface — the test-first-way. I know for sure that this may not really work in a way that I want it to, so I can go ahead and change bits and pieces to suit my needs.
• Write a test harness like cactus for every such possibility — this I know is a crazy solution but one that would gurantee testability. This would also create additional problems of having to maintain the test harness at a pace equal to the pace of what the harness is trying to test.