It’s going to be a rather “big meetup”:http://web1.2020media.com/j/jez/javanicuscom/londonjava/items/141-index.html tonight – I’m looking forward to a minor religious war over groovy with “James”:http://radio.weblogs.com/0112098/ and fellow groovy developers on one side, “Hani”:http://www.jroller.com/page/fate/ and “Simon”:http://www.brunningonline.net/simon/blog/ on the other. I’m on the side that says “most developers don’t know how to use Java properly, let alone anything dynamic!”, and so will be anti-everyone.
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…
Thanks have to go out to Simon, who yet again as “uncovered a gem(Fail Fast)”:http://www.brunningonline.net/simon/blog/archives/001460.html of a post over at his blog. Mike Mason’s “Null is bad, hmm-kay?”:http://mikemason.ca/2004/07/03/#040NullIsBad makes the point that when creating new method skeletons (for example when auto-generating methods from tests) the default IDE behaviour is typically to do nothing (in the case of void returns) or return null. Even worse, when auto-generating a method with an array return type IDEA will return the following code:
public Object[] getSomeArray() {
return new Object[0];
}
This can often result in problems tracking down why a test is failing (or even why normal code is failing) as the unimplemented method is being called, a null is being returned and passed on, and when an error does occur it can often happen quite some way from the original method call.
A better approach of course is to throw an exception from the auto-generated method body detailing why you shouldn’t be calling it. This is a simple matter in IDEA and I’m sure the other IDE’s out there. Flush with my new knowledge I mentioned this to a colleague by way of a helpful piece of advice, only to find he already did it. There is a lesson to be learnt there I’m sure…
The subject of testing abstract classes came up recently. Imagine the following scenario – I have a class @AbstractBob@ which provides an implementation of a method @callFred@. @ConcreteBob@ extends @AbstractBob@ and implements the required methods – at this stage it doesn’t override @callFred@. Now what would you test? There are several approaches I can think of:
# Just test the concrete class
# Test the methods defined in the abstract class by creating a stub implementation, then test the methods explicitly implemented in the concrete class but not those implemented in the abstract.
# Create an abstract @TestCase@ (or whatever – depends on your testing tool) which tests those methods implemented in the abstract class. Then, subclass for testing your concrete class
Continue reading…
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.
magpiebrain 