Eclipse and TDD (Part 2)
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.
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.
Kerry Buckley
14 Oct 07 at 2:44 am
Ah, now I think I see what you’re saying. I work in Ruby, not Java, so that initial exploration is even more exploratory; the “interface” I’m calling could be anything at all, dynamically-defined methods, maybe even methods that don’t really exist. Usually, there’s some documentation, but if not, I have to poke through the library source code to see what it’s expecting and what methods it provides.
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.
Jay Levitt
14 Oct 07 at 4:46 am
I’m somehow not sure what you are trying to question, but let me just share my limited TDD experience with Eclipse in context you described.
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.
Nirav Thaker
14 Oct 07 at 9:01 am
Kerry Buckley wrote:
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.
Ketan
15 Oct 07 at 1:14 pm