Tuesday, September 29, 2009

Wednesday, September 9, 2009

Tips for dealing with DB2 database samples in your product

In trying to ship a sample of the ITM (IBM Tivoli Monitor) database utilized by our product, we stumbled upon the cross-platform restrictions of the backup/restore commands for DB2, which state:
The supported platforms for DB2 backup and restore operations can be grouped into one of three families:
  • Big-endian Linux® and UNIX®
  • Little-endian Linux and UNIX
  • Windows®
After hours of fiddling with DB2 manuals and succeeding partially in moving the data from an DB2 in AIX 64 bits to a Windows 32 bits machune, I eventually stumbled upon this great developerWorks article, fittingly titled: Using DB2 utilities to clone databases across different platforms.

Essentially it uses a combination of the “db2move” and “db2look” commands, like this:

Exporting the data

To export the contents of the database, change to the directory where the exported directory where the files should be written and run:
db2move WAREHOUS export -sn ITMUSER
db2look -d WAREHOUS -e -a -o db2look.sql
where WAREHOUS is the name of the database I was exporting and ITMUSER the schema for it.

Importing the data

Copy over the files to the target machine and change to the directory where the exported files are. Then run the command:
db2 “create db WAREHOUS”
db2 –tvf db2look.sql

db2move WAREHOUS import
where WAREHOUS is the name of the database you are importing.

You can use a different database name, but you need to edit the first line of the db2look.sql file to match the name.

Thursday, September 3, 2009

Unit testing tools, a minimalist toolset.

After wading through the sea of unit testing tools out there, here is a minimalist (and so far, sufficient) set of open-source tools for testing server-side centric Java code.

----

JUnit 4.x

That is almost a given, full integration with Eclipse and Ant, standard in the industry, etc, etc. JUnit 4.1 is the last release where I did some thorough investigation of any new function, though the just released JUnit 4.7 (Aug/4th) has some function I would like to explore.

----

DDTUnit (http://ddtunit.sourceforge.net/)

This is the best alternative for data-driven testing, where the test code is small but has to use different data inputs.

Side comment:This presentation cross-compares DDTUnit with other data-driven approaches:

Tip: The syntax for the test XML data can be a chore, but this Eclipse snippet (with instructions) can help:
http://sourcepatch.blogspot.com/2009/08/ddtunit-and-eclipse-snippets.html

----

JMock (http://www.jmock.org/)

This library allows you to pre-program objects in the JUnit testcase with the "right" responses to exercise the target code.

----

JMockit (https://jmockit.dev.java.net/)

This library is used to replace Java calls ordinarily not under your control with code under your control.

For instance, you can intercept a call to DriverManager.getConnection and return your own implementation of java.sql.Connection.

Tip 1: This library requires you to add -java.agent=build_dir/libraries/test/jmockit/jmockit.jar to the unit execution path.
Tip 2: Avoid it if you can, it makes tests slower and harder to follow. If you have another entry point to pass a JMock object, such as setter method, do it.



Links I have bookmarked about unit testing recently: http://delicious.com/nastacio/unit-testing