Sam Newman's site, a Consultant at ThoughtWorks

Archive for ‘July, 2004’

Recently there has been much talk of the perceived deficiencies in JUnit. Much of this discussion has focused on the implementation issues of JUnit, but none of them have actually addressed if JUnit (or a rewrite of JUnit) is actually suited to one of the main areas it is being used in, namely in Test/Specification Driven Design. As I “mentioned before(magpiebrain – It’s time to drop the ‘T’ from TDD)”:, the constant reference to the word ‘test’ can lead to a misunderstanding of what TDD actually is – one proposed solution was to drop the word ‘test’ altogether. Others are looking at writing tools which can more closely match what we are trying to achieve with test/specification driven design.

As part of my month long period helping run London’s “Geek Night”:, we’ll be having a presentation of JBehave, which is being written as a JUnit replacement. Rather than simply attempting to reproduce method call for method call what JUnit does, it is changing the language used in an effort to help change the developers mindset, whilst at the same time improving support for other specification techniques such as mock objects. Personally, I’ve yet to actually see the thing running, so I’m hoping the demo will at least be informative! “Nat Pryce(Mistaeks I Hav Made)”: is also threatening to demo his latest project, although I still don’t fully understand it so it’s best to come along and see for yourself…

_[Update 11:44, 19/07/2004]_ : Nat sent this along to explain what his tool does:

It’s a way of specifying “tell don’t ask” object-oriented code that addresses some of the limitations of mock objects and can be used to generate useful documentation.

If you want to pop along and see if it’s any good, make comments, heckle, throw rotten fruit or whatever, just pop along to the “Geek Night Wiki(Geek Night London 21 July 2004)”: and put your name down. Any questions (like how to get there), feel free to “drop me a line”:

By no means am I an AOP expert, but the claims made by a recent “devx article”: (spotted thanks to “John Flinchbaugh(Dynamic Proxies)”: ). Entitled “Java Dynamic Proxies: One Step from Aspect-oriented Programming” made me want to comment. It claims that:

…once you understand proxies, you’ve made a small conceptual leap towards the bigger picture—aspect-oriented programming (AOP)

Firstly, dynamic proxies, have nothng to do with AOP. Sure, they can be used to accomplish some AOP goals in the way they allow code to be dynamically wrapped around methods, but they are a means to an end. AspectJ doesn’t even use dynamic proxies – it inserts Aspects using compile-time sourcecode manipulation. The use of dynamic proxies in AOP is an implementation detail, not something inherent in the use of AOP.

You might gain some understanding as to how some of the AOP frameworks implement Aspects by learning about dynamic proxies, and you might even get a good feeling of the power provided by dynamically inserting code, but you are a long way from fully understanding the complexities of AOP.

Courtesy of Warren Ellis, via his blog “Die Puny Humans(Die Puny Humans – not work safe)”: (in no way safe for work!):

“sure, buy yourself a cute little Apple. Then save yourself some time and money by throwing the fucking thing out of the window, going out again and getting yourself a proper bloody computer”

It’s going to be a rather “big meetup”: tonight – I’m looking forward to a minor religious war over groovy with “James”: and fellow groovy developers on one side, “Hani”: and “Simon”: 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”: 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)”: of a post over at his blog. Mike Mason’s “Null is bad, hmm-kay?”: 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…