Overview Parameterized Tests with JUnit

Gerard Meszaros's describes in his great book with the title xUnit Test Patterns a pattern with the name Parameterized Test. This blog post describes how the pattern can be implemented in a JUnit 4.X test. The post compares three different options.

1. JUnit Parameterized Test

The JUnit framework comes with a runner for parameterized tests. The parameters are defined by a static function which is marked with the annotation @Parameters. The JUnit Runner is called Parameterized.

Example: 
Output - Eclipse JUnit View: 

Advantages
No extra framework or library for parameterized tests is needed. The JUnit view in eclipse and also in other IDEs works fine. One test with one defined parameter set can be invoked via the JUnit view in eclipse.

Disadvantages
The output from the tests is not clear. The output shows only the index number of the used test parameter. Only one test data model and parameter set per test class.

2. More JUnit Parameterized Test in a Test Class

It is possible to have more then one parameterized JUnit test in one test class by using the experimental runner "Enclosed".

Example: 
Output - Eclipse JUnit View:

Advantages
Grouping logic tests together in one class. Each test can be run from the JUnit view, a single test can be executed for debugging.

Disadvantages
Lots of boilerplate code of the embedded classes.

3. TwiP

TwiP is JUnit extension for parameterized tests. The library brings a JUnit runner, which is named "TwiP".

Example: 
Output - Eclipse JUnit View: 

Advantages
More then one parameterized test in a class is possible. Mixing parameterized and not parameterized tests is possible in one test class. Clear test output toString() method is used for the test parameters.

Disadvantages
A single test could not be chosen from the JUnit output (Eclipse JUnit view) and could not be invoked. This makes debugging the tests difficult because always all test combination must be executed to debug one failing test with one special combination.

4. JUnit Params

JUnit Params is another JUnit extension for parameterized tests like TwiP. The essential difference between TwiP and JUnit Params are the syntax how to define the parameterized tests.

Example: 
Output - Eclipse JUnit View: 

Advantages
Same advantages as TwiP and a little bit clearer test output then TwiP.

Disadvantages
Same disadvantages as TwiP a single test could not be invoked.

5. Summary

A perfect solution for a parameterized test in JUnit does not exists. TwiP and JUnitParams provided the way I like to write parameterized tests. But TwiP and also JUnitParams test cannot be debugged a single test can not be executed. I think the problems lies in the JUnit design for the descriptions and not in the TwiP or the JUnitParams project. Hope there will be a better solution in the future. So it's a difficult choice

Performance Apache Common StringUtils Split and Google Guava Splitter

Last Friday I have a discussion with a colleague at SEITENBAU about the semantic of the split method of the Apache common lang StringUtils class. At the end we have compared the Google Guava Splitter API with the Apache commons Lang StringUtils split methods. Our opinion after that is that the source code based on Guava could be better understood and is much clearer.

After comparing the APIs, we have thought about which of the two APIs has the faster split implementation. So I have build simple performance test for the two String split implementations. The result has surprised me. The StringUtils split method is in my test case much faster then the Guava Splitter split method.

Test setup is I generate 5000 random strings with a length of 10000. The test strings contains commas to split the strings in the test. I invoke the Apache common spilt method and the Guava Splitter with the same test data, the performance result is shown in the table bellow.

Test Runs	1	2	3	4
Apache Common StringUtils.split(…)	126 ms	122 ms	121 ms	122 ms
Google Guava splitter.split(…)	352 ms	350 ms	346 ms	349 ms

Here the source of my simple performance test:
Why
Has anybody an idea why the Guava API in my test is slower then the StringUtils split method? I read that the Guava Splitter performance should be very good. Therefore, I am surprised about the result.

Here the dependencies I have used for the performance test:

Equinox CM and ECF inconsistent Behavior

This evening I had a long OSGi debugging session with the Equinox Configuration Admin and ECF based Remote Services implementation. In the end I found out, it was my mistake used configuration admin wrong. And I update this blog post.

But the problem is that the behavior of the configuration admin depends on which bundles calls the createFactoryConfiguration(...) method and this makes debugging hard.

The problem was that when I create the first time a factory configuration via my remote bundle (which is running on the same system local in other OSGi framework), I become a exception. The remote bundle invokes the method "createWall(…)" see the code sample:

When the first caller of this method was the remote bundle I become the following exception (when the second caller of the configuration admin is a local bundle got the same exception, e.g. when a configuration is created via the apache webconsole):

When the same logic is called first time from a local bundle everything works fine. After some time of debugging, I found the issue. The point is not that the bundle is local or remote.

In the implementation of the method "createWall(...)" the Configuration Admin method "createFactoryConfiguration(...)" with location null is used. The JavaDoc of this method says, when this method is called the first time, with location null, then the location of the first bundle is used which register a service.

OSGi Compendium Specification JavaDoc for the createFactoryConfiguration says:

"The Configuration is bound to the location specified. If this location is null it will be bound to the location of the first bundle that registers a Managed Service Factory with a corresponding PID."

In my case the first bundle was sometimes indirect the remote bundle. So I have the problem and become the exception. My fix was to set the location to the bundle location of the bundle which creates the wall configuration, see the code sample:

In end I found out, that the two OSGi frameworks has the same configuration area, the same local directory. Provider an host are running on the same system. It was a coincidence that the fix work. If the PID for the configuration folder was not locked by the other OSGi instance everything works. So in the end I must say it is my mistake because the OSGi instances had the same directory configured as configuration area. But the design that the location depends on the first caller makes debugging crazy. Does anybody know if this is the expected behavior? This is really hard to debug, that the directory where the configuration is stored could depend on the first caller. What is the best practice set the location parameter always?

Groovy Closures and Annotation Parameters

Since Groovy 1.8 there is support to have a closure as a parameter in annotations. A nice example how to use this feature is the GContracts project, a groovy design by contract framework, which use closure annotation parameters, to define pre and post conditions of a method.

The support of closures in annotations provides a simple way to have much more dynamic in annotations. This is cool and provides new areas where you now could use annotations. Here a simple example how a closure as annotation parameter could be used to group properties.


More details about closures in annotation see the groovy 1.8 release notes.

Links:

• http://groovy.codehaus.org/Groovy+1.8+release+notes#Groovy18releasenotes-Closureannotationparameters 
• https://github.com/andresteingress/gcontracts

Crazy Scala Combinator Parser

Updates

• 2012-06-?? Add Chris Hodapp version to the post.
• 2012-06-23 Fix word is now in the second sample no method anymore its a val

Create my first parser with the Scala combinator library. I really like the concept to have simple way to compose simple parsers via high-level functions to a complex parser. But I think the syntax for the internal Scala parser DSL is a little bit crazy. I’m not sure why the method names in Scala always must be as short as possible e.g. rep. For me this makes the source of my simple parser really crazy. Here my first simple key value parser to show how the source of Scala parser looks like.


The concept behind the Scala combinator parsers are great, try it and you will learn a lot about how to create a parser in functional language. But I don’t understand why always the shortest and cryptic methods names are used in Scala. This type of naming makes the source hard to read and understand and it makes the Scala source so crazy. But when you know the cryptic names it makes a lot of fun to write such crazy Scala source.

Try it more details about regex parsers please see the Scala doc. The demo parser is not perfect and I’m not a Scala professional, if there are any comments feel free write me how to make it better.

A better Scala version of the parser by Chris Hodapp here: Links

• http://www.scala-lang.org/api/current/index.html#scala.util.parsing.combinator.RegexParsers

Groovy Declared Fields Filter Synthetic

Groovy generates some "synthetic" field to a class, that means the reflection method getDeclaredFields returns more fields than fields which are declared in the Groovy source of a class. To filter the "synthetic" fields the Groovy grep method could be used e.g. "anyClass. declaredFields.grep { !it.synthetic }".

Links

• http://stackoverflow.com/questions/6069513/can-we-get-declared-properties-of-a-groovy-class-by-its-order

Grails and Spring @Async Annotation

If some logic e.g. in a grails service should be invoked asynchronous, in Grails 2 the spring annotation @Async can be used. For that the spring annotation driven task support must be activated in the spring configuration. To activate the task support, the task namespace should be added to the spring configuration. Here a sample spring configuration ("resources.groovy").


Now the spring annotation can be used to mark e.g. service logic which should be invoked asynchronous. Here a sample to send mails asynchronous (for sending the mails the grails mail plugin is used).



For more details see also the spring framework documentation:
http://static.springsource.org/spring/docs/current/spring-framework-reference/html/scheduling.html#scheduling-annotation-support-async

Start buggy lazy Bundles

Yesterday I push to github a simple bundle, which I use in bnd and bndtools to activate buggy lazy bundles.

What is a buggy lazy Bundle?
Sometimes I have bundles with a Bundle-ActivationPolicy header, which is set to lazy. But no other bundle in the application loads classes from this bundle or use a service e.g. via DS from this bundle. In some cases the lazy bundle didn’t export anything.

When you like to use such lazy bundles, then this bundle must be start by hand. Examples are the Eclipse  ECF bundles. To use the ECF bundles (see also ticket ID-373475) some of the bundles must be start by hand because of the Bundle-ActivationPolicy header lazy. I think these are buggy bundles and the Bundle-ActivationPolicy header should be removed from the manifests.

When you use lazy bundles then this bundles should automatically started by the OSGi framework, when some other bundle in the application need the functionally of the lazy bundle. Think about before you use the Bundle-ActivationPolicy lazy. Only use lazy bundles when the OSGi framework could detect that some other bundle would like to use functionally which the lazy bundle provides.

Examples use lazy bundles when the bundle exports packages with classes and only when some other bundle loads a class from these exported packages the bundle should be in state active. Or when the bundle provides an OSGi service via DS and the bundle should only be in state active when some other bundle would like to use this service. So be careful with using the Bundle-ActivationPolicy header.

More about lazy activation bundle see the OSGi Alliance web site here.

Handling buggy lazy Bundles in Bnd
When you like to use a buggy lazy bundle with bnd or bndtools the bundle must be started by hand. For this I create a simple bundle, which I call “Start lazy Bundles”. The bundle implements an extender pattern which watch for starting bundles. When the starting bundle has a Bundle-ActivationPolicy lazy and the bundle symbolic name is set in a system property the “Start lazy Bundles” bundle try’s to start the bundle.

More details see the Github project:
https://github.com/tux2323/Start-lazy-Bundles

Lambdaj Closure in Java

Yesterday we played around with the Lambdaj project. The project provides a fancy way to simulate closure in Java. Here some simple examples based on the lambda4j documentation code.



And here a second example with "delayedClosure", which shows how to read a file line by line with lambda4j.



More details about lambda4j please have a look at the project website:
http://code.google.com/p/lambdaj/

Eclipse Equinox ECF Unpack *pack.gz

If you downloading Eclipse ECF as a ZIP file, the plugins folder in the ZIP contains pack200 compressed JAR files. The pack200 compressed files ends with *.pack.gz. The ECF ZIP distribution contains the same content like a normal Eclipse P2 update site.

If you like to use Eclipse Equinix ECF bundles without P2 or Eclipse you must unpack the pack200 OSGi bundels. For that eclipse provides a tool called "org.eclipse.equinox.p2.jarprocessor". Here a small bash script to show how to extract the OSGi bundles from the pack200 files.



Links

• Eclipse Pack200 Documentation - http://wiki.eclipse.org/Pack200
• Eclipse ECF Download Page - http://www.eclipse.org/ecf/downloads.php