One option is to develop a quick-and-dirty spike to gain an understanding of what you need to do, then throw it away and re-code it, this time using TDD.

That is definitely a good option, but a really cumbersome one, to be frank. There are tons of API that I’m talking about. Hitting new API everyday, spiking it out, and then doing TDD is I’d say a big pain-in-the-ass.

Most of the important Eclipse interfaces are well documented but reading docs doesn’t ascertain what it will do (for example API of an IAdaptable returning IAdaptable means it may do anything). Eclipse can’t give solid test framework like Spring because of it’s size (there are just too many things in Eclipse) but what it provides (test APIs in the famous classes) is good enough together with tools like PDE-JUnit (TPTP, http://help.eclipse.org/help32/topic/org.eclipse.hyades.test.doc.user/concepts/cintro.htm), not excellent though.

So I would say you should definitely know the contract before you implement or mock arbitrary interfaces, and Eclipse generally doesn’t kick into your application unless it depends too much on Eclipse internals (which is a design smell anyway). And as you know it, assuming is never a good idea in software development in general.

I’ll admit that when I first start playing with a library, I may write a “hello world” type program just to see if I’m making the right calls in the right order. But even then, it’s not hard to do that “hello world” in JUnit; just assert that the output of the routine is “hello world”! Sometimes I even cheat at first, and leave off the assertion; as long as the test gets to the end without crashing, I know I’ve done something vaguely right, and then I can think about how to test the outcome.

That maps most closely to your first and second method – play around a bit, read the docs, make sure you’re not totally in the dark, and then do it test-first. You definitely don’t want to go down the road of #3; don’t write tests for things you don’t use.

Having never done any Java programming, let alone Eclipse, I can’t be more specific without seeing an example. But, coincidentally, one of my upcoming projects is to try to add some unit tests to a popular Eclipse plugin that doesn’t currently have any (using the “start with a bug report” method), so this problem is intriguing. If you’re so inclined, you can drop me an e-mail at “jay at jay dot eff-em” with some more concrete info on what you’re implementing, and maybe we can walk through unit-testing it together.