magpiebrain

With “IDEA 4.5”:http://www.jetbrains.com/idea/index.html due out any day now (no doubt Javablogs will be bombarded with product announcements when it happens) I had a look at the forthcoming changes. Whilst a couple of things looked quite handy (such as structural search and replace or improved code duplication checks) there are a few things I’d like to see added:

* If I create a new class prefixed with @Abstract@, I’d like the class created abstract too – this could of course be tailored to individual coding guidelines, so all those Visual Basic refuges prefixing abstract classes with @A@ will be catered for
* If I create a class with an @Impl@ suffix, like @BobImpl@, and IDEA knows of an Interface called @Bob@, it will automatically create the class as a @Bob@ implementation.
* If a class has a test, e.g. @BobImpl@ has @BobImplTest@, then IDEA will provide a link from @BobImpl@ to @BobImplTest@ and vice-versa. A link similar to those provided to show implemented in/implementing method links would be great.
* Given that IDEA understands more links between classes/interfaces, e.g. @Bob@, @AbstractBob@, @BobImpl@, @BobImplTest@, that the refactor->rename would more consistently renamed ‘linked’ classes
* It would be fantastic if IDEA picks up normal code edits as being refactor operations – for example if I change the name of a class by editing, IDEA pops up a dialog asking if I want to perform a refactor->rename.
* A spell checker!
* A Thesaurus to help me with naming…

No matter whether you call it Test Driven Development or Test Driven Design, many people now accept that the use of the word test is at best misleading and at worst can result in fundamental misunderstanding of what TDD is about.

TDD at its core is the process of defining expected behaviour of your code,make your code match the expected behaviour, refactor, and so the cycle goes. The problem is that presently the only way we have to define the expected behaviour is using test tools such as JUnit. I’ve lost count of the number of people who have become confused over TDD, and have ended up thinking that because their code was developed using TDD that its fully (unit) tested – its not, you just wrote enough tests (specifications) to drive out the behaviour of the system.

We need a new name – call it Behaviour Driven Design, or Specification Driven Design or whatever you want (I’m sure I’m not the first person to use either terms). We need new tools – as long as we use unit testing tools to specify behaviour people will still get confused about what they are actually doing. Even a JUnit clone with different names would go a long way to fixing the misunderstanding. I am of course being slightly disingenuous on that final point – I know some new tools are coming. But without a better understanding of what Specification/Behaviour Driven Design is really about, the new tools will be pointless.

I’m currently writing a UI layer for Naked Objects. I’m using a TDD approach and have also used the development as an excuse to give “JMock”:http://www.jmock.org/ a go. It being my first experience using a proper Mock Objects API (I have used the very handy “MockRunner”:http://mockrunner.sourceforge.net/, which Mocks application frameworks rather than objects) its been slow going at the start. Things have now started to click into place mentally and JMock is at last making some sense.

Today however I hit a really annoying problem. I’m developing a simple @FrameFactory@, who when given a @NakedClass@ will return a window showing a list of instances. The code looks like this:

public class FrameFactory {
  public FrameFactory(FactoryDependancy dependancy) {
    ...
  }

  public Component makeInstanceList(NakedClass clazz) {
    //make an instance - this is what I want to test
  }
}

Continue reading…