Groovy, mock objects friendly?
[ vmassol ] 14:49, Saturday, 30 August 2003

James Strachan has posted a news about starting a new dynamic language for the java platform called Groovy. He mentions using it for writing unit tests a la JUnit.

I think that's an excellent idea! On most projects I've been on, writing good unit tests often comes late in the development. Usually people write functional or integration tests but rarely unit tests which test code in isolation from the rest. And once the design best practices have been decided and lots of code has been already written, writing unit tests is hard because it requires severe refactoring and design changes. The hard part is the introduce mock objects in the code under test. Some code uses statics, other instanciate domain objects instead of them being passed to it, etc.

Of course, extreme TDD practictioners would say that it is much better to refactor the code under test so that it become more flexible and better able to support change. That's true but that's difficult to practice for the majority of projects and difficult to apply if the project has not been started the TDD way.

What would be nice is to have a dynamic language geared towards introducing easily changes to the code so that it can support the mock objects approach. There is a unit testing framework out there that does almost this; it's called AgileTest from Polygenix.

Maybe Groovy could extend the ideas from AgileTest and become a generic dynamic language to easily insert mock objects (among other things)? Sprinkle this with an AspectJ-like syntax and you've got something quite nice!

I know I'm probably changing the original idea but what I'd love to have is a language purely geared towards unit testing

What do you think?


Comments

A language where unit tests are naturally integrated would be nice. I suppose my only concern with making mock objects or AUT or any of those things easy is that too many people will use them and stop there.

As you write, it is not always practical to refactor applications to be more testable, but will these tools merely make it easy for most programmers to test their untestable designs and still drown under the next wave of changes coming around the corner? Will the illusion of "my design is 'testable'" give the programmer a false sense of security in the face of real design changes?

I don't know, but I worry about it.

--J. B. Rainsberger, September 29, 2003 11:23 PM
Post a comment









Remember personal info?