Writing Unit-Tests for Java in Groovy: Not so brilliant after all?

August 17, 2009 | 1 Minute Read
This post was originally posted on my old blog.

Update 2009-08-18: I did only get halfway to true enlightenment... Dierk König was so kind to correct me in his comment (see comments bellow). Thanks!

There is advice out there, that it is a good idea to use Groovy for unit-testing your Java code. The following developerWorks article is a good example for this idea: Practically Groovy: Unit test your Java code faster with Groovy

There is even the opinion, that writing tests in Groovy can be a good starting point to secretly sneak Groovy into your Java project.

Dierk König was giving an interesting talk at gr8conf presenting "Seven Groovy usage patterns for Java developers".

Using Groovy for unit-testing would best fit the "House Elf"-pattern, along with using Groovy for build automation, deployment and functional tests.

But Dierk König did not mention unit-testing in his presentation!

When questioned about that, Dierk König gave an interesting answer:

Unit-Tests are ideally realized with Test Driven Development (TDD). But TDD is more about design than about testing, the resulting unit-tests are just a convenient by-product of the process.

So unit-tests should be a design tool, a mean to drive and evolve the underlying code.
Dierk König argued, that ..

...in order to achieve the goals of TDD, unit-tests should be written in the same language as the underlying code.

Sounds pretty obvious to me...

It is clear that this is only valid for true unit-tests. Integration-tests and functional-tests are a completely different story. I think thats the area where more expressive languages like Groovy can shine.

Thats probably also a reason why the real BDD scene seems to prefer Ruby and Groovy...