Why - yes, I do!
This week we have visitors. We invited two experienced consultants to do a quick review of our source codes. Of course, we are very convinced to write good source code. In this we are no different from any other programmer. Mind you, it's just the same with car drivers: Virtually every car driver is convinced to drive better than the average car driver :). Do I have to mention our Java code is better than the average - er - ...?
Obviously, this can't be true, and this is why we invite external code reviewers on a regular basis. It's always good to be asked why we do what we do. The review weeks are always a great source of inspiration, of new ideas, and of course, the reviewers always find a couple of bugs we've missed. Review weeks are always a lot of fun, by the way.
I already knew this week's reviewers to be very experienced, so I was caught in surprise be their question:
You don't seriously want to write your JUnit tests in Groovy, do you?
Why - yes, I do!
Why I frequently choose Groovy as a JUnit language
Truth to tell, I'm far from being a fluent Groovy speaker.[1] Currently, I use Groovy as a relaxed Java dialect. And that's great when it comes to writing tests. Be honest: is it fun to write a JUnit test? Almost every programmer prefers writing programs to writing code to test programs. Even the most convinced Test Driven Developer has to admit that writing tests does slow down progress in the short term. There may be benefits in the long term, but you have to invest heavily in the short term.
So the obvious question is how to reduce the investment. The most common answer is to drop JUnit tests completely. A better idea is be to make writing JUnit tests more attractive.
That's why I like to write JUnit tests in Groovy. As I mentioned, you can use Groovy as a sloppy dialect of Java. It takes less key strokes to write your tests. You can write your tests faster. You can return to programming business logic earlier.
Why should I refrain from writing test in Groovy?
Our company has a rule. The rule is: Every piece of valuable business code has to be written in ABAP. If you can't write it in ABAP, write it in Java.
But this doesn't affect non-productive code. JUnit tests may be valuable - they are not productive code. They are much less valuable. Mind you: if your JUnit test suite is lost, you can always rewrite a it provided you've still got the production code. But can you reconstruct the production code if it's lost - except for the test suite?
Imagine a cross word puzzle. It's hard to solve it from the clues, but once it's solved, it's easy to invent new clues. The same applies to production code and its JUnit tests.
So I suppose even if you insist on a Java-only production environment, there's no point in forbidding Groovy tests. If you were to do so, you'd also have to forbid Gradle build scripts. The next logical step is to forbid Maven build scripts, as well as ANT build scripts. Both are programming languages build on XML. Like it or not, once you've adopted Java as a programming language, you've adopted polyglot programming - and it's very hard to find reasons to forbid a particular JVM language.
Can your crew cope with Groovy JUnit tests?
That's the real question, and it's not a question you should ignore lightheartedly. If your staff doesn't feel comfortable with Groovy, you shouldn't torment them with Groovy JUnit tests. Of course, the same applies to every other language: you can write tests in Scala, Clojure, Dart, Ceylon or whatever language you like. At the end of the day, your work-mates have to cope with the tests, so you should choose the test language according to their taste. In many teams, Java is the least common denominator, so it's a natural choice.
JUnit tests as a starter drug to another language?
Yes, that's a common strategy, and it's not a bad strategy. As I mentioned, JUnit tests are valuable code, but they are a lot less valuable than the real production code, so it's a good idea to conduct your experiments on your test code first. If the experiments goes well, you can safely expand the experiment to production code.
In my example, it's a good idea to try Groovy (or Scala, or Clojure, or Dart, or whatever) in the JUnit test code base first. It's a good risk limitation strategy. If your team happens to cope with the invention badly, little is lost.[2] If your team embraces the invention, they'll use it eagerly in production code.
Conclusion
I've spent some time thinking about whether I do want to write Groovy JUnit tests in serious, but the answer isn't difficult:
Yes, I do! I do want to write JUnit tests in Groovy. Seriously!