Leonardo Borges

I never paid too much attention on testing database stuff. While working with java, the closest I got to something workable was using the test case abstractions provided by the Spring framework. It ensures that each test method runs in its own transaction that is rolled back after the test’s execution.

Fair enough. I used the setUp() method on my TestCase to configure some records so I could work with them, removing all of them in the tearDown() method. It was quite simple and worked.

But I always felt something strange with this solution. First of all, I had to add another framework just for that. - Actually I was using spring for dependency injection, but if I wasn’t, it wouldn’t be a nice option. And another thing that bothered me, is that you cannot guarantee that your database is in a known state.

After I started to work with Ruby - and Rails - I discovered the testing fixtures. It is a really nice way to set up your testing data without having to worry about your database state. - If you don’t know what I’m talking about, follow the above link first.

Then I received a message from a co-worker saying he was having some trouble in using DBUnit with Hibernate, and asked for some help. I’ve heard of DBUnit before but never tried it myself. It was a very good opportunity to take a better look into it.

The basic idea after all is very similar to that of the Rails Fixtures: You have some sort of external file - XML in this case - where you set up the testing data. So the framework takes care of erasing the database, inserting your test data and returning it to its original state.

So far so good, DBUnit’s default Classes works with JDBC, DataSources and JNDIDatasources, but not with Hibernate. The effort to put them working together is minimal and is documented in their web site.

I decided to share how this can be done with hibernate and in the end, you would have a test case similar to this one:

Continue reading »

[2008/04/30] Update: The ibm_db gem has been updated to support the new Rails 2.0 style migration. Now you can just use t.xml and it will work. Look here for more info. Thanks to Mario Briggs for pointing me to the update.

—

In my new job we work with XML data natively stored on DB2. I have done some test with Rails and DB2 a few weeks ago and it’s pretty interesting, specially the easiness that Rails deals with XML.

We decided to test some new features of DB2 9.5 and I decided to test them with Rails 2.0.

So I created a new Rails app, configured the database.yml to use the idm_db gem and fired:

$ rake db:create

The output is nice but, the database isn’t there! I suppose it’s something with the gem that needs to be updated. But really don’t know about it. It just doesn’t work. But this will not hold us down. I will just create the database by hand and keep going with my tests.

After that, I created a new model XmlDocument, which has a column named data, of type XML. According to the new migrations syntax, my model’s migration would look something similar with this:

class CreateXmlDocuments < ActiveRecord::Migration
def self.up
create_table :xml_documents do |t|
t.xml :data
t.timestamps
end
end

def self.down
drop_table :xml_documents
end
end

Right? Ok, I fired up a terminal and lauched:

$ rake db:migrate

The output? Here it is:

== 3 CreateXmlDocuments: migrating ============================================
-- create_table(:xml_documents)
rake aborted!
undefined method `xml' for #


Yes, a big nice exception! The new migration syntax doesn’t allow you to do t.xml! But please don’t ask me why! :p
The solution? Well, although it’s weird - imo - , it’s also easy. You can mix the new and the old syntax in the same file. So our model’s migration will now look like this:

class CreateXmlDocuments < ActiveRecord::Migration
def self.up
create_table :xml_documents do |t|
t.column :data, :xml
t.timestamps
end
end

def self.down
drop_table :xml_documents
end
end

And that’s it! We’re ready to go! I didn’t find anything else different so far, besides what I described here. Hope this helps!