magpiebrain

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)”:http://www.magpiebrain.com/archives/2004/07/05/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”:http://geeknight.thoughtworks.com/index.php/GeekNight, 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)”:http://nat.truemesh.com/ 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)”:http://geeknight.thoughtworks.com/index.php/GeekNightLondon21July2004 and put your name down. Any questions (like how to get there), feel free to “drop me a line”:http://www.magpiebrain.com/contact.

By no means am I an AOP expert, but the claims made by a recent “devx article”:http://www.devx.com/Java/Article/21463 (spotted thanks to “John Flinchbaugh(Dynamic Proxies)”:http://www.hjsoft.com/blog/showArticle.java?id=223 ). 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.

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…

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…

“Rome”:http://wiki.java.net/bin/view/Javawsxml/Rome is another Java API which provides RSS parsing capabilities. Unlike the more mature “Informa”:http://informa.sourceforge.net it also supports Atom. Their comparison with Informa makes interesting reading – they state that Informa is hard to use! The mind boggles – here is how you can parse a feed:

FeedManager feedManager = new FeedManager();
FeedIF feed = feedManager.addFeed(getUri());

What is complicated about that? It’s true that Informa doesn’t support Atom yet, but that is a trivial task and support should be in soon (Niko is working on it now). Their only other complaint seems to be that Informa can only 1.0 and 0.91 in output – this is a valid criticism but RSS output never core to Informa’s goals. In any case adding support for other export mechanisms is trivial but to my knowledge has never been requested by anyone.
Continue reading…

In a recent trend of technologies being used as verbs (think _googling_, and err, well something else) of late I have been mostly Naked Objecting. For those who don’t know, “Naked Objects”:http://www.nakedobjects.org/ is a framework which allows the developer to quickly roll an application which provides both a UI and persistence layer simply by coding a domain model (for a better overview see ” Introduction To Naked Objects”:http://today.java.net/pub/a/today/2003/07/15/nakedaddress.html over at Java.net). Thats the good side.

That bad side is that the built in default ‘lightweight’ UI just plain sucks. It makes heavy use of drag and drop which is not in itself a bad thing, however its a jolt for those users more used to a standard UI, and no non-drag and drop alternatives are provided. It is also ugly, and not that intuitive. Luckily, Naked Objects make it fairly easy to roll your own UI for it, something I’ve been playing around with over the last few days.
Continue reading…

With a view to adding “Atom”:http://atomenabled.org/ support to “Informa(Java RSS API)”:http://informa.sourceforge.net/, I started looking into the specification in more detail. Just before I started looking at adding support for the syndication format, and found out that Niko (Informa’s product manager) was already looking at it. Instead, I decided to look at the posting and editing API. A “WSDL(Atom’s WSDL file)”:http://atomenabled.org/developers/api/AtomAPI.wsdl file was available, but “Axis(Apache Axis Web Services API)”:http://ws.apache.org/axis/ wasn’t too successful at converting it into a Java API. To get wsdl2java to actually process the file, I had to remove the @DELETE@ operation. I then hit the limitations of my knowledge as far as we services are concerned, so this has been put on the back burner while I read over some tutorials. I’ll keep you informed as to Niko’s progress on adding Atom syndication support to Informa

Using “HttpClient(Apache Commons – HttpClient)”:http://jakarta.apache.org/commons/httpclient/ I knocked up a simple Java API for “del.icio.us(del.icio.us – the social bookmark manager)”:http://del.icio.us/. It worked, but I quickly hit limitations of what the “del.icio.us API(Documentation for the del.icio.us API)”:http://del.icio.us/api/ itself would let me do – for example there is no way to get all bookmarks for a category. I sent off a feature request, so we’ll see what happens – but for what I wanted to do the current API isn’t good enough.

HttpClient itself did exactly what I wanted, which I guess is all you can ask of an OS project. The documentation was a little lacking, and the dependencies on “commons-codec”:http://jakarta.apache.org/commons/codec/ and “commons-logging”:http://jakarta.apache.org/commons/logging/ was annoying, however it worked well and gave sensible errors when required.

Along the way I looked at using “XStream”:http://xstream.codehaus.org/. I was planning to use it to process the results from the calls to del.icio.us, but the nature of the XML meant that this isn’t possible without transforming the results first. I would have no hesitation in recommending XStream for XML serialization, assuming you aren’t already constrained in the nature of your XML schema.