Skip to main content

Advantages and Disadvantages using Groovy for Unit Test (JUnit)

I'm collecting the advantages and disadvantages using Groovy for JUnit and found following interesting stuffs...

Advantages:
  • You don't need to implement inner classes which are very awful and bloat your test codes. Instead you can use closures. Using closures for writing your mock objects can make your test codes smaller and more compact!
  • File operations are very easy to implement thanks to AntBuilder. How many times do you need to make some file operations (delete, mkdir, ...) within your test codes? Doing this with java.io is not fun at all. Using AntBuilder for this purpose is a good thing, since Ant is predestinated to do this job. If you think that you could do the same thing in pure Java, you will find that this takes a lot more work. Using Ant directly in Java is unfortunately not straight forward. Example: to use the unzip Ant task you need to use the Expand Java class, which is not documented properly (so you need to dig into the Java source code). In AntBuilder you just use the same structure like your Ant file: unzip!
  • If you are using SpringFramework you can easily create the config files (application context) by using BeanBuilder. By using this concept you don't need to put separate XML files in your test project. Everything is integrated and centralized in your test class!
  • If you are using Ant for your build environment, you can integrate the compilation of Groovy classes easily since Groovy also offers an Ant task.

Disadvantages:
  • No source code formatter for Groovy: This is a real disadvantage for Groovy at the moment. If you are working in a team this could be a nightmare: reading the code with different formatting, CVS compare is difficult, ... are some examples to mention...
  • The Groovy plug-ins (code completion, syntax coloring, ...) - at least for Eclipse - is still very buggy.
  • You need to learn some new concepts like: closures - which is also an advantage after you understand them! Without closures you cannot implement inner classes in Groovy, which are mostly a must in writing unit tests.
The good thing about using Groovy for your unit tests is that you don't have to make the choice between Java and Groovy at one time! You can move slowly from Java to Groovy - of cource if you feel that you are more productive using Groovy to write your unit tests - as you wish and mix Java and Groovy unit tests in the same project!

A good place to start for Groovy and Testing is right here: Groovy Testing Guide.

If you have some points to add please let me know!

Cheers,
Lofi.
Labels:

Comments

lofidewanto said…
A discussion about this topic can be found at JavaLobby:
http://www.javalobby.org/java/forums/t94245.html

Cheers,
Lofi.
1:52 AM
Post a Comment

Popular posts from this blog

Why "Polyglot Programming" or "Do It Yourself Programming Languages" or "Language Oriented Programming" sucks?

Last year we saw the launch of a new Web programming language Dart - Structured Web Programming from Google. A very interesting approach to support web application development. Not so long after Go, Groovy, Ruby, Scala, << name your DSL here >> ; we see Dart. Is it a good thing to have at least one programming language to solve one problem? The answer is, like we already know, it depends. Some important backgrounds you should know about the multi programming language paradigm are following: 1. You can read Martin Fowler article about language oriented programming with language workbenches which enables you to write small programming languages easily. In this article I see everyone writing their small languages, everywhere. In this concept we see DSL (Domain Specific Language) as the future of our programming activities. Source: http://martinfowler.com/articles/languageWorkbench.html 2. Neal Ford talked about Polyglot Programming, combining multiple programming language...
32 comments
Read more

Software Development Macro and Micro Process

If you think that in year 2012 all companies which produce software and IT divisions in our world have already their optimized software development process, you are wrong. It seems that we - software architects, software developers or whatever your title is - still need to optimize the software development process in many software companies and IT divisions. So what do you do if you enter a software company or IT division and you see following things: 1. There is a perfect project management process to handle all those development of software but it is a pure project management without a context to software development. So basically you only take care of cost, time, budget and quality factors. In the software development you still use the old fashioned waterfall process. 2. From the tooling point of view: you have a project management planning and controlling tool but you are still in the beginning of Wiki (almost no collaboration tool) and you don't use issues tracking sy...
20 comments
Read more

Creating Spring Bean dynamically in the Runtime

In my training someone asked me whether it is possible to create an object (a Spring Bean) dynamically so you can choose which implementation you want to have  in the runtime . So at the compile time you don't know what object actually should be created yet. The application should decide what object to be created based on a property file . 1. We create an annotation so we can mark the method which should be able to create the object dynamically: ... package your.package; ... @Retention(RetentionPolicy.RUNTIME) public @interface InjectDynamicObject { } ... 2. Use the new created annotation in your method which should be able to create the object dynamically: ... @Named("customerBo") public class CustomerBoImpl implements CustomerBo { ...     @Override   @InjectDynamicObject   public Customer getDynamicCustomer() {         return this.dynamicCustomer; } ... 3. Write an aspect with Pointcut a...
10 comments
Read more