Andres Almiray's Weblog

On July 18th Eitan released a new version of JMatter, which includes many improvements and support for forms created with Abeille Form Designer (more on that later), but there is also another feature currently in svn that will give you more freedom in the regard of what a command may return. JMatter commands may return 3 values, handled by the framework as But now we have a fourth option: JComponent, when one is returned the framework will automatically wrap it in a generic View, relieving the developer of creating such a view. There is already demo-app bundled with JMatter (Self) which has a command that will display a JPanel with animations, so I thought that it may be great to test the fourth option and what better way to do it by embedding Google Maps support into the app, don't you think?

JMatter comes with another demo-app called Sympster, which is a Symposium Manager, modeled after the format of the NoFluffJustStuff Symposiums; each Symposium has a Venue, a venue may be a Hotel, a Conference Center or a Campus. As it currently stands a Venue only has a name and a list of rooms, we're going to add an address so that we can map it. We're going to use Groovy for the view because it is so simple to create custom UIs by hand with it (see previous post) and also because configuring JXMapViewer with it is pretty straightforward, as Guillaume Alleon and Guillaume Laforge show here and here.


Because it is a generic view, it doesn't have a title nor a custom icon. There may be an option in the future to do just that, perhaps with clientProperties or with a properties file. The point is that we concentrated our efforts on modifying the Model and provided a custom view without having to merge the view with the framework itself. These type of views may come in handy when doing quick app prototyping and then when the design has been approved you can get fancy with icons, colors and custom names & labels.

Keep on Grooving! and don't forget to stop by JMatter if you're into form-based business applications on the desktop

groovy howto jmatter swing

Another announcement of the week is the release of FEST 0.3 (here and here), a great milestone for Yvonne & Alex. I've exchanged information with them about adding Groovy support to FEST, so I decided to believe in my own words first and take FEST for a spin with Groovy UIs.

There are a couple of articles out there that show how to use FEST (previously know as TestNG-Abbot), I picked the examples shown at Andy's In pursuit of code quality: Automate GUI testing with TestNG-Abbot, following the spirit of TDD, I started with the test and later moved to the real code.

Here is the test code:
package swing import java.awt.Dimension import org.fest.swing.* import org.fest.swing.fixture.* import org.testng.annotations.* class TestWordFinder { private FrameFixture window @BeforeMethod void setup() { window = new FrameFixture( new WordFinder().frame ) window.show( new Dimension(300,200) ) } @Test void assertDefinitionPresent() { window.textBox("wordValue").enterText("pugnacious") window.button("findWord").click() window.label("answer") .requireText("Combative in nature; belligerent.") } @Test void assertNoWordPresentInvalidText() { window.textBox("wordValue").enterText("") window.button("findWord").click() window.label("answer") .requireText("Please enter a valid word") } @Test void assertNoWordPresentUnknownWord() { window.textBox("wordValue").enterText("Ha77") window.button("findWord").click() window.label("answer") .requireText("Word doesn't exist in dictionary") } @AfterMethod void tearDown() { window.cleanUp() } }
Notice something strange? anything missing? no? well the code is Groovy code (you can tell by the missing semicolons and public modifiers) but other than that is equal to a 100% Java TestNG testcase, and that makes FEST amazing, it's fluent-interface design makes coding tests a breeze, and it behaves like a DSL, you don't need to use Groovy to get to this level of abstraction (but it doesn't hurt either, right?).

To run the test you'll need TestN'Groove (or groovyng), you can grab a bin distribution from the project site and follow the README for installation instructions. As I prefer to manage my dependencies with maven, a copy of the groovyng-1.0.jar gets installed on my local repo. After that its just a matter of configuring a basic Ant build with the following targets:
<target name="groovyng" depends="compile.groovy"> <java classname="org.codehaus.groovy.testng.GroovyTestNG" fork="true"> <classpath> <path refid="build.classpath" /> <pathelement location="${maven.build.output}" /> </classpath> <arg value="-d" /> <arg value="${maven.test.reports}" /> <arg value="${basedir}/src/test/groovy/swing/TestWordFinder.groovy"/> </java> </target>
Its time to code the UI that will make the tests green:
package swing; import javax.swing.SwingUtilities import javax.swing.WindowConstants import groovy.swing.SwingBuilder class WordFinder { private SwingBuilder swing def frame def dictionary = [ "pugnacious": "Combative in nature; belligerent." ] WordFinder(){ swing = new SwingBuilder() frame = swing.frame( id: "frame", title: "WordFinder", defaultCloseOperation: WindowConstants.EXIT_ON_CLOSE ){ vbox { hbox { label( "Word:") textField( id: "wordValue", name: "wordValue" ) } label( id: "answer", name: "answer", text: "Please enter a valid word") button( id: "findWord", name: "findWord", label: "Find Word", actionPerformed: this.&findWord ) } } frame.pack() } def findWord = { def word = swing.wordValue.text if( word ){ swing.answer.text = dictionary.get(word, "Word doesn't exist in dictionary") }else{ swing.answer.text = "Please enter a valid word" } } void setVisible( boolean visible ){ frame.visible = visible } static void main(String[] args) { SwingUtilities.invokeLater { new WordFinder().setVisible(true) } } }
Notice that each widget has an id and name properties, the first one assigns an internal variable with that name into the SwingBuilder and serves as a reference to the component, the second one will let Abbot find the component during tests. The findWord closure uses the fact that SwingBuilder has a reference of the components to locate the TextField and retrieve its text, the query on the dictionary uses a clever trick available to Maps, it calls get() with a default value, which will be stored and returned if no value is assigned to the key, the next time the same key is requested, the default value will be retrieved directly from the Map.

I hope this little demonstration has made you excited about trying FEST (an Groovy!), I know I am. I really wish FEST was available a year ago, when I was in the middle of a project (desktop app) which required a lot of user interaction, had a lot of paths and many options that had to be proven before letting it into the wild. We looked at Abbot at that time but deemed the learning curve too steep for our time constraints and decided to go with a home-brew solution (highly tied to our architecture, making it neigh reusable). Now I look at FEST and see what I was expecting 12 months ago, and it is on version 0.3, imagine what's coming next!

Congratulations to Yvonne and Alex for a fine work, truly remarkable.

Keep on Groovying! and don't forget to test

fest groovy howto testing

If you're into Groovy you've probably know that there is built-in annotation support since release 1.1-beta-1 but "unfortunately" it will only work for the following parameters and local variables are still allowed by the parser but they are pretty much left aside (for now?). But did you know that there is a way to annotate closure parameters and have access to those annotations? by using a custom GroovyClassLoader. Jochen blogged about it a while back (ChitChat with the Groovy Compiler) and in case you're wondering this is one of the tricks Grails uses to inject properties to your domain classes; essentially by subclassing the GroovyClassLoader you can provide your on CompilationUnit "handler", and we need to do it this way because the annotations we're targeting can't be accessed at runtime. Now that we have covered a bit of theory, let's get this party started!

Running AnnotationTester will yield the following output:


You'll find more info about annotations and Groovy at Annotations with Groovy, there's even an example of annotations on method parameters, Using Popper with Groovy.

Keep on Groovying!

annotations closure groovy howto

Lately I've been messing around with SwingBuilder, and as you probably know, when building Swing apps you usually have the impulse (need?) to code quick event adapters as anonymous classes, but Groovy does not support anonymous classes.. or does it? SwingBuilder already supports a shortcut for components that can register an ActionListener, as that interface has only one method, you define a closure and the builder takes care of the wiring with actionPerformed. But what if your listener has more than one method? no problem, Groovy Maps and the as keyword come to the rescue. If you didn't know, you can cast any Map (or any object for that matter with proper type support) to any other object, but what makes Maps special is that when used with conjunction with the as keyword it behaves like an anonymous class definition!

Take for example the following code, which is part of the test suit of the upcoming JideBuilder (I'll post about it later): def count = 0 def animatorListener = [ animationStarts: { component -> count = 0 }, animationFrame: { component, totalStep, step -> count += 1 }, animationEnds: { component -> } ] as AnimatorListener def jide = new JideBuilder() jide.panel(){ button(id: "button") animator(id: "animator", source: jide.button, totalSteps: 9, animatorListener: animatorListener ) }
By specifying a map key of type Closure and then "casting" the Map to the proper type you obtain an instance of the specified type, just as if you were defining and instantiating an anonymous class, how cool is that? Just be sure to provide the complete list of parameters of each "implemented" method, otherwise you'll get an exception.

Keep on Groovying!

groovy howto

Parts I & II. Going further with the experiment of using Fuse with Groovy I had the goal of having a 100% Groovy app running, as I previously mentioned, I only accomplished that by compiling Groovy to byte code and running the app with Java.

The good news is that its possible! I was having classpath problems, which prevented the Fuse injectors to locate the theme files, you may run your own example with a similar configuration as the one being shown next: <path id="groovy.classpath"> <!-- jars --> <path refid="build.classpath" /> <!-- compiled Java classes and resources --> <pathelement location="${maven.build.output}" /> <!-- Groovy scripts --> <pathelement location="${basedir}/src/main/groovy" /> </path> <target name="run.groovy" depends="setup"> <copy todir="${maven.build.output}"> <fileset dir="src/main/resources" /> </copy> <java classname="groovy.ui.GroovyMain" fork="true" classpathref="groovy.classpath"> <arg value="${basedir}/src/main/groovy/swing/GroovyMain.groovy"/> </java> </target>
Notice that I'm not using the Groovy Ant task, but instead running the main Groovy interpreter, that is because it seems there may be an issue with that task and its classloaders, so then again, this solution works for the time being when testing your app with Ant tasks.

Keep on Groovying!

fuse groovy howto swing

This is a follow up of Fusing with Groovy. After a couple of tries to get a custom UI component annotated with Fuse coded in Groovy to work, I decided to talk to the pillow and let the issue aside. The next morning I noticed I was always running the tests with the Groovy interpreter (from 1.1-BETA-1 of course) and decided to try again, but with the Java interpreter instead. Lo and behold , it worked!

So it's possible to create an UI component in Groovy, annotate with Fuse and inject resources, provided that you compile the code into byte code and run it with Java (for the time being). I'm sure it will be possible to do the same with the Groovy interpreter in the very near future.

The code I tested was a slight modification of ContentPanel (provided by the demo), which is the same code but with a little syntactic sugar on it.
package swing import java.awt.AlphaComposite import java.awt.Composite import java.awt.GradientPaint import java.awt.Graphics import java.awt.Rectangle import java.awt.RenderingHints import java.awt.image.BufferedImage import javax.swing.JPanel import org.jdesktop.fuse.InjectedResource class GradientPanel extends JPanel { @InjectedResource GradientPaint backgroundGradient @InjectedResource BufferedImage light @InjectedResource float lightOpacity protected void paintComponent(Graphics g) { if( !this.visible ) return Composite composite = g.composite; g.setRenderingHint(RenderingHints.KEY_INTERPOLATION, RenderingHints.VALUE_INTERPOLATION_BILINEAR) g.paint = backgroundGradient Rectangle bounds = g.clipBounds g.fillRect(bounds.x as int, bounds.y as int, bounds.width as int, bounds.height as int) g.composite = AlphaComposite.getInstance(AlphaComposite.SRC_OVER, lightOpacity) g.drawImage(light, 0, 0, getWidth(), light.getHeight(), null) g.composite = composite } }
Note that there is no need to cast Graphics to Graphics2D and some methods as setPaint() and setComposite() are treated as properties, oh, and no semicolons as well

Keep on Groovying!

fuse groovy howto

Recently Daniel Spiewak announced the availability of Fuse 0.4, having worked on a custom solution for resource injection I decided to give Fuse a look, as I remembered that it was used in a little app that astonished everyone at last year's JavaOne, I'm talking of course about Aerith.

I usually configure my projects with maven + eclipse, after adding the Fuse jars to my local repo and setting the Eclipse classpath, everything is ready to start hacking. The first thing to do is get a sample app with Fused resources, so I grabbed a copy of SwingHive demo and everything works as expected, you get a nice looking black gradient frame and two buttons, labeled "Black Theme" and "Red Theme", when you click on the red one, the gradient changes to a red hue, when you click the black one, the gradient returns to its original state.

So far so good, now its time to make the demo Groovier using the SwingBuilder, the resulting code follows:
package swing import java.awt.BorderLayout import java.awt.FlowLayout import javax.swing.JFrame import javax.swing.SwingUtilities import javax.swing.WindowConstants as WC import org.jdesktop.fuse.SwingHive import groovy.swing.* class GroovyMain { private SwingHive hive private JFrame frame def changeTheme = { theme -> hive.load(theme) } public GroovyMain() { hive = new SwingHive() changeTheme("/swing/black.uitheme") def swing = new SwingBuilder() frame = swing.frame( title: "Fuse/Swing (Groovy) Demo", size: [640,480], resizable:false, locationRelativeTo: null, layout: new BorderLayout(), defaultCloseOperation: WC.EXIT_ON_CLOSE ){ widget( buildControlPanel(swing), constraints:BorderLayout.SOUTH ) widget( new ContentPanel(), id: 'content', layout: new BorderLayout() ){ widget( new HeaderPanel(), id: 'header', constraints: BorderLayout.NORTH ) widget( new TitleLabel("Fuse/Swing (Groovy)"), id: 'title', constraints: BorderLayout.CENTER ) widget( new FooterPanel(), id: 'footer', constraints: BorderLayout.SOUTH ) } } // inject resources ['content','header','footer','title'].each{ hive.inject swing."${it}" } } public void setVisible( boolean visible ){ frame.visible = visible } private Object buildControlPanel( swing ) { swing.panel( layout: new FlowLayout(FlowLayout.TRAILING) ){ button( label: 'Black Theme', actionPerformed: { changeTheme("/swing/black.uitheme") }) button( label: 'Red Theme', actionPerformed: { changeTheme("/swing/red.uitheme") }) } } public static void main(String[] args) { SwingUtilities.invokeLater { new GroovyMain().setVisible(true) } } }
Notice that because the main frame is composed of custom UI elements, it is required that widget() be used to append the elements to the frame (If you can't wait for James to finish SwingXBuilder, you may insert Swinglabs components in this way), resource injection is done iterating on properties set at the SwingBuilder instance (use the 'id' property for that) and that button interaction is pretty easy with closures. Executing this class with the Groovy Eclipse plugin yields the same result as before, but we chopped 70 lines from the original Java source =)

The next logical step would be to create a custom UI component in Groovy with resource injection ... and this is where I got stuck, neither the Eclipse plugin, maven mojo nor Ant task will let me inject a resource into my Groovy component, perhaps I'm missing something.

For the time being, here is a list of resources I found useful to get this little example to work:
Keep on Groovying!

fuse groovy howto swing

I've been reading again The PickAxe for a while and one thing that keeps "haunting" me is how easy (and weird) is to create overloaded operators, the weird part being the name of the method call, which in Ruby is the operator itself. There is an example on the book on how to overload the index ([]) operator, so that it may receive two args; I tried to visualize how to do the same on Groovy and came with the following solution, I'll not reproduce Dave's full example [get the book to see the rest! =)], instead I'll post something similar, but you'll get the idea.
Ruby Version:
class Song attr_accessor :title, :artist, :duration, :start_time def initialize( title, artist, duration ) self.title = title self.artist = artist self.duration = duration self.start_time = 0 end def [](from_time, to_time ) s = Song.new( self.title + " [extract]", self.artist, to_time - from_time ) s.start_time = from_time s end end song1 = Song.new( "Dream On", "Aerosmith", 600 ) song2 = song1[0,100] song2.title == song1.title + " [extract]" song2.artist == song1.artist song2.duration == 100
Groovy Version:
class Song{ String title String artist int duration int startTime = 0 def getAt( arg ){ if( arg instanceof List ){ return arg.size() == 2 ? subSong(*arg): null }else{ super.getAt arg } } def subSong( from, to ){ new Song(title:title+" [extract]", artist:artist, duration:to-from, startTime: from) } } def song1 = new Song(title:"Dream on", artist:"Aerosmith", duration:350) def song2 = song1[0,100] assert song2.title == song1.title + " [extract]" assert song2.artist == song1.artist assert song2.duration == 100
The trick in Groovy is to override the default getAt() that all beans inherit from the default Groovy MetaMethods, query the type of the arg, if it is a List, and in this case of size == 2, we call the subSong() method and return that Song, null otherwise. If the arg is not a list, we let the super class handle the call. The Groovy code to handle the overridden index operator may not look as fancy as the Ruby one, but it is very easy to mimic the same functionality and get the same results.

Keep on Groovying!

UPDATE: Following Dierk's suggestions, here is the updated Groovy version:
class Song{ String title String artist int duration int startTime = 0 def getAt( Range range ){ new Song(title:title+" [extract]", artist:artist, duration:range.to - range.from, startTime: range.from) } } def song1 = new Song(title:"Dream on", artist:"Aerosmith", duration:350) def song2 = song1[0..100] assert song2.title == song1.title + " [extract]" assert song2.artist == song1.artist assert song2.duration == 100

groovy howto ruby

Continuing the saga of Groovy applets, Grapplet is now groovier (I'm not kidding) the source is 100% Groovy now. I noticed that while JSObjectGroovyInterceptable was a plain Java class, the title on the sample JFrame was not correctly presented, instead of displaying 'Groovy', the default Object.toString() was displayed. I suspected the cause was in the signature of invokeMethod( String name, Object value ), changing to Groovy and leaving the value type undefined did the trick. I also added an each() method that will work on JS arrays, so it's possible to invoke a Groovy closure on each element of a JS array

Grapplet is temporary hosted at Json-lib's site, you may find it at http://json-lib.sourceforge.net/grapplet/grapplet.html and the 'binary' distribution at http://json-lib.sourceforge.net/grapplet/grapplet.zip. You'll need to configure your security settings to accept the certificate and grant permissions. I recommend that you download the binary distribution and try it locally, as the invoking mechanism will make several roundtrips to gather all the classes it needs. In my previous post I showed the security settings I followed, here I present the steps you'll need to test the applet from Json-lib's site:
Here is another sample Groovy sample script that you may want to try, but first you must create a JavaScript array, filled with integers, on the window (easy if you use the JavaScript Shell for FireFox)
s = '' window.array.each{ s += "${it as int}" } s


Keep on Groovying!

applet grapplet groovy howto
Let's say that your JavaScript array is [1,2,3,4], the Groovy script should output '1234'. If the type coercion to int was not made the output would be '1.02.03.04.0' instead. Feedback is always appreciated.

It took me a while (because work has been so intense lately) but I have a working version of Groovy in the browser as Dion did with Ruby. The good news besides running Groovy with <script type="text/groovy"> is that its also possible to call JavaScript code between your Groovy code without triggering a SecurityException (but I think its related to my security settings somehow, more on that). Dion's version included a tricky but clever way to read all <script> tags from the document with JavaScript and later feed them to a dynamically created JRuby applet. This version does the same but adds support for JSObject (as it was in the last post). For now you may run a script an use the 'window' reference to get a hold on the JS world; but if you try to use that variable inside a class, you'll have to declare it as an explicit field or property, obviously this feature should be handled in a groovier way and inject it to any class that is declared in the script.

I'm making the source available from this site (download here) but remember that this is still a work in progress, it shouldn't be used in any production environment!

In order to run the applet you'll need to sign it (or accept my certificate). The first time I did this experiment, the signing process was smooth but with this version I ran into some trouble, knowing that others may want to try it too, I present the steps I followed to get it running, perhaps you'll notice that a step is superfluous or unnecessary, please let me know. You've surely noticed that although the applet's full URl would be 'http://localhost/grapplet/' the policy file refers to 'http://localhost', I don't now why (yet) but the applet said several times that its codebase was the later URL instead of the former, perhaps I should have specified a codebase directly.

Uff, that was a little long but those are the steps I followed to get my Groovy FireFox going on, yep, I haven't tried it with IE or Safari yet, on Dion's page someone said that the dynamically applet tag should be created in a literal way in order to get it working on Safari.

Scott, if you're reading this, please notice that I know I should have started this work by buying a mac

Keep on Groovying!

applet grapplet howto roovy

Jochen has recently posted an article on the Visitor Pattern, but design pattern aside, the article shows how easy is to migrate from a 100% Java code to Groovy code, demonstrating again why Groovy is a great glue language for the JVM.

groovy howto

Romain Guy has posted an update on Groovy and JPA. He had to use the latest snapshot (1.1-SNAPSHOT) to access annotation support. Now that we now a way how this can be accomplished we'll see how the Grails team assimilate the info (JPA basic support is scheduled for 0.7 [Grails Roadmap]).

annotations groovy howto

Previously I demonstrated how to work with in-memory databases with DbUnit and enabling one-time setup & teardown on a JUnit 3 TestCase. Now I'll show how to apply the TestDecorator to a DBTestCase to accomplish the same feat but allowing for code reuse.

The TestDecorator works with a TestSuite, which in turn handles an instance of your TestCase for every test that is run; the TestSuite does not provide and easy way to invoke arbitrary methods on the instances, so the TestDecorator appears to work in a static way from the TestCase point of view; so how do we pass the database configuration to the decorator?
We could try with a ThreadLocal but that will entangle and complicate our setup, besides tying our tests to a only one scenario (no ThreadLocal from the decorator, no working test), another solution must be found. Tipically when testing with an in-memory database you'll probably use a subclass of DBTestCase or JdbcBaseDBTestCase, but because DBTestCase uses an internal PropertiesBasedDatabaseTester that pulls its configuration from System.properties, there is no need for an extra artifact to do the configuration, the tester (any PropertyBasedDatabaseTester) will use the same configuration (this may pose a problem when in a multithreaded, multitest environment, but that may not be your case).

The code to read and process our DDL is very simple and should be in its own utility class. Putting all pieces together yields the following:
Without further ado here is the sample code from the TestDecorator:
package testing.db; import java.sql.Connection; import junit.framework.TestSuite; import org.dbunit.PropertiesBasedJdbcDatabaseTester; public class DDLTestDecorator extends OneTimeTestDecorator { private PropertiesBasedJdbcDatabaseTester dbTester; public DDLTestDecorator( TestSuite test ) { super( test ); dbTester = new PropertiesBasedJdbcDatabaseTester(); } protected void oneTimeSetUp() throws Exception { Connection connection = dbTester.getConnection() .getConnection(); DDLUtils.executeDDL( connection, "testing/db/create-database.ddl" ); } protected void oneTimeTearDown() throws Exception { Connection connection = dbTester.getConnection() .getConnection(); DDLUtils.executeDDL( connection, "testing/db/drop-database.ddl" ); } }
And the code for the testcase:
package testing.db; import junit.framework.Test; import junit.framework.TestCase; import junit.framework.TestSuite; import org.dbunit.Assertion; import org.dbunit.IDatabaseTester; import org.dbunit.PropertiesBasedJdbcDatabaseTester; import org.dbunit.dataset.IDataSet; import org.dbunit.dataset.ITable; import org.dbunit.dataset.xml.XmlDataSet; public class DecoratedDbEnabledTestCase extends TestCase { public static Test suite() { return new DDLTestDecorator( new TestSuite( DecoratedDbEnabledTestCase.class ) ); } private ClassLoader classLoader = Thread.currentThread() .getContextClassLoader(); private IDatabaseTester dbTester; public DecoratedDbEnabledTestCase( String name ) { super( name ); System.setProperty( PropertiesBasedJdbcDatabaseTester.DBUNIT_CONNECTION_URL, "jdbc:hsqldb:mem:sample" ); System.setProperty( PropertiesBasedJdbcDatabaseTester.DBUNIT_DRIVER_CLASS, "org.hsqldb.jdbcDriver" ); System.setProperty( PropertiesBasedJdbcDatabaseTester.DBUNIT_USERNAME, "sa" ); System.setProperty( PropertiesBasedJdbcDatabaseTester.DBUNIT_PASSWORD, "" ); } public void testDataSetOne() throws Exception { IDataSet databaseDataSet = dbTester.getConnection() .createDataSet(); ITable actualTable = databaseDataSet.getTable( "C_CUSTOMER" ); // Load expected data from an XML dataset IDataSet expectedDataSet = getDataSet( "testing/db/dataset2.xml" ); ITable expectedTable = expectedDataSet.getTable( "C_CUSTOMER" ); // Assert actual database table match expected table Assertion.assertEquals( expectedTable, actualTable ); } protected void setUp() throws Exception { dbTester = new PropertiesBasedJdbcDatabaseTester(); dbTester.setDataSet( getDataSet( "testing/db/dataset2.xml" ) ); dbTester.onSetup(); } protected void tearDown() throws Exception { dbTester.onTearDown(); } private IDataSet getDataSet( String fileName ) throws Exception { return new XmlDataSet( classLoader.getResourceAsStream( fileName ) ); } }
The code for the DDLUtils helper class is the same as in the previous posts so I'll not show it again. You'll notice that it is the TestCase that defines the database properties to establish a connection, but because the properties are defined in System.properties it is possible to define those properties at runtime. With little extra code it is also possible to refactor the suite() method, querying System.properties to find out if we return a decorated suite or just a simple suite, in this way the code may work for in-memory database test that need to create its own schema, or a normal test that access a database that has an already defined schema.

Keep on testing!

dbunit howto testing