REVERT TO CONSOLE

This is postmodern computing at it’s finest…

I’m a fairly recent convert to test driven development. I’ve always thought it seemed like the right thing to do, but have only recently bought into it whole-heartedly when I took over someone else’s code base and was told the requirement’s have changed and I needed to modify it without knowing what has changed.

After writing 50+ new unit tests, I started looking for a way to streamline the process, in the form of one of the multitudes of dynamic languages now available to java. JRuby, jython, and beanshell were the favored options, as I see it (groovy looks like a promising option too, but it seems like they can’t get a 1.0 release out). It’s my understanding that beanshell has passed the latest round of jsr votes and will be a part of the jdk in the future…

Anyway I woke up in bed tonight thinking there ought to be some way to really streamline this process in Eclipse…

So imagine this:

You’re adding a new method to an existing project. Eclipse is managing the set of project dependencies, and will quickly tell you what you’ve broken after you’ve written it… and that’s great; you’ve got this wealth of information at your disposal… but doesn’t that just beg for a new plugin???

Ok, imagine, you’re writing this new method… and you can instantly move into a beanshell with an eclipse context… so you can dynamically interpret the results of your method… which is fine for simple methods with primitive signatures, but more than likely you’ll have complex objects to deal with… so add something that will generate an Easymock object for you and pass it into your beanshell and dynamically modify the context.. to help you flesh out your method with the benefit of knowing how the method will behave without the test/write/compile step. And once you’ve done that and are happy with the results, why not generate a Junit test class as a result???

So the flow would be like this; you write your method signature, create your EasyMock object(s), flesh out your method in a beanshell so you know it works correctly, and generate a Junit class with the final product.

The more I think about this, the more beneficial it seems…