Alexandru Popescu: TestNG and Groovy

Alexandru Popescu is the co-founder of TestNG, the next generation testing framework for Java, which also happens to be Groovy friendly. Continue reading to learn about his thoughts on TestNG/Groovy and some other exciting topics. Enjoy!

[img_assist|nid=2502|title=|desc=|link=none|align=right|width=129|height=133]Andres Almiray: Alex, you are the co-founder of TestNG, what got you into the project ?

Alexandru Popescu: There is quite a long history here, so I'll try to be as short as possible. A couple of years ago while working within a large engineering team we have faced quite a few problems caused by the rapid changes in the product requirements, changes that were not captured in the documentation or any other systems. The team had really hard times to meet the deadlines and deliver due to the endless discussions related to the requirements. So, we were looking for a reliable way to formalize our requirements. We have even tried to update ourselves the documentation, but, pretty soon, we have figured out that we are not the best writers. Also, it was kind of difficult to show the direct correlation between the documents and our functionality. As a result, we have started to try out all existing testing frameworks in our attempt to have a "code based" requirement set. Unfortunately, even if we spent time extending (and bending those frameworks) to fit our needs we have run into the limitations of using unit testing frameworks for more advanced scenarios like functional testing. By that time I've met (online) Cédric Beust who was just releasing the first version of TestNG: a testing framework that should simplify functional and integration testing. The framework was running only on the newly released Java 5, so over a weekend I have ported it to run on JDK 1.4, which was the platform targeted by our products. Afterwards I have joined the project and also created the Eclipse plugin for TestNG. Last, but not least, I would like to thank our community who has contributed a lot of valuable ideas that have helped us to keep evolving the project.

Andres: How do you see Groovy and TestNG working together ?

Alexandru: When I started experimenting with this idea, I have imagined a very simple path to follow: prototype your tests in Groovy scripts -- thanks to Groovy you would be able to focus only on the tests and leave aside the boilerplate code. Then once your code would be done and the tests are passing you would move them back to Java sources and integrate them in your different suites. However, things have changed a lot since I've started. Now the IDE support for Groovy got a lot better and we are also having the joint compiler, so there is no need to switch back to Java.

Andres: Can you share what lies ahead in TestNG's future ?

Alexandru: According to the feedback we are receiving both on the mailing lists and privately, TestNG is used in more and more advanced scenarios.  Moreover, people are finding the current set of features challenging and they are trying to suggest improvements. Currently, we are not having very specific plans, but we have started to experiment with some core changes that would allow our users to get even further with TestNG features. And we are always listening to new suggestions.

Andres: How did you get involved with Groovy ?

Alexandru: I have heard of Groovy a couple of years ago. At that moment I was involved with other open source projects and also considered it a bit too young, so I've just put a note somewhere to check it sometime later. Fast forwarding, in 2006, the Groovy team has finally released the 1.0 version and that was the moment that triggered my old note. I have played with it a bit and starting to enjoy its features. The next step was almost natural considering my history with TestNG: what if I put the two together so that prototyping and testing gets even simpler? I have figured out that a couple of features needed for this interaction were not yet included (e.g. annotations), so I've started implementing those (this was quite easy as in the past I have had worked a lot with Java bytecode since my involvement with the AspectWerks AOP framework). Then I have followed the normal process: a couple of bug fixes, some more small features, some evangelizing, all these resulting in the project lead, Guillaume Laforge, proposing me to join the team, which I've been very happy to do.

Andres: Do you use Groovy at work ?

Alexandru: The short answer is yes, we are using it, but we are just starting. The long answer is that we are not currently using Groovy inside our core products, but it is becoming our scripting language "de jour". So, for the moment we are developing most of our administration scripts using Groovy and we are planning to migrate old ones to it.

However, considering its perfect interaction with Java (which is the platform of our products) and having in mind its power (but also simplicity) I have some big plans for putting Groovy to more work inside products. It is a bit early to talk about this, so more about this with the next occasion.

Andres: What would you like to see in Groovy 2.0 ?

Alexandru: I'll start by saying that I am pretty happy with the evolution (in terms of features and also performance) Groovy has seen since the release of 1.0 version. The core team has done an amazing job. However, there are a couple of things that I would definitely like to see happening sooner than later. Basically this are falling in two big categories: language consistency and performance.

I'll start with the second and I'll say that performance has got a lot better since the 1.0 release and is improving with each (even minor) release. Now, all this work is done against the already available API (so preserving the behavior and API) and this is making things a bit more complex. I have had this discussion with the core team a couple of times in the past and my opinion is that maybe instead of trying to fix the unfixable we should revisit some deep details of the implementation and take the right decisions that will allow the performance engineers to make Groovy scream. Getting back to the other part of my wishlist: small improvements for enhancing the language consistency. While these are not visible to all users, being more related to features used by frameworks, I do think that we should bring as much consistency to the language as possible. At the moment, Groovy is offering one of the most powerful metaprogramming capabilities around languages like Ruby, Python, etc. Unfortunately, there are cases where working with these features is not the best experience (sometimes due to the constraints for , sometimes due to the fact that the core hasn't allowed a better implementation) and I think we can do much better. So, just to avoid any possible confusions I am referring to instance metaclass handling, metaclass behavior when inheritance is involved, categories and default Groovy methods (aka GDK). In the last couple of months I have started to gather ideas and I have been submitting proposals and suggestions about these corner cases, so I have high hopes that these things will get much better in the next versions.

Andres: What about Mixins ?

Alexandru: I have been looking myself at mixins/traits for a long time and I have even tried to add support for them in Groovy through external libraries. Interestingly enough, these two terms are very present in a lot of languages, but there is no common definition for them. However, if we agree to look at them as a way to enhance the functionality of existing classes and so to increase the modularity of our application, I assume everybody would agree that they would represent a nice addition to the Groovy environment. It is up to the core developers and to the community to decide what exact definition and implementation these will take in Groovy and how far we need to go from existing "similar" concepts in other languages, including Java. 

Andres: Which of Groovy's features you like the most ?

Alexandru: I would say that the most important thing for me is the fact that Groovy runs on the JVM and its seemingly interoperability with existing Java code. Adding to these the GDK, the XML support and the support for closure are already making Groovy very attractive. And I should emphasize that I am mentioning here just a few of the existing features that would make a programmer more productive.

Thanks Alexandru!

Alexandru's bio

Alex Popescu is Chief Architect and co-founder of InfoQ.com. Alex is interested in bleeding-edge technologies (AOP, advanced testing) and has been spending more and more time on various scripting languages. Alex is involved in many open source initiatives, being co-founder of the TestNG testing framework and a committer on Groovy, WebWork and a couple more OSS projects. Alexandru formerly was one of three committers on the AspectWerkz project before it merged with AspectJ. Alexandru also publishes a blog on tech topics at http://themindstorms.wordpress.com.