Unfortunately I had a lot of problems getting the required software setup working, which included PostgreSQL, pgTAP, Test::Harness, make and perl. Ultimately I wasn’t able to get the examples running due to imcompatabilities between PostgreSQL and pgTAP on my Macbook Pro (OS X 10.5.8) and ended with this error:

dyld: Library not loaded: /usr/local/lib/libxml2.2.dylib
Referenced from: /Library/PostgreSQL/8.4/lib/postgresql/pgxs/src/makefiles/../../src/test/regress/pg_regress
Reason: Incompatible library version: pg_regress requires version 10.0.0 or later, but libxml2.2.dylib provides version 9.0.0

I considered trying to upgrade libxml, but there were suggestions that this could cause my machine to not boot! I even considered upgrading to OS X 10.6 (Snow Leopard), but decided that this was a little too close to shaving yaks.

I would really like to get more familiar with pgTAP at some point, but I will have to put on hold for now…

Update: I managed to get some input from David Wheeler, worked through the technical issues and got all the tests running. Thanks David! Despite the earlier setup problems, I came away with a very positive feeling about TDDD and pgTAP and can see it playing a part in any future database schema development I do.

The talk was given by Chris Bedford, from Build Lackey Labs – “Automating the Monkey Work Out and the Quality In!”. Overall, I thought this was a great talk by Chris. He clearly has a huge amount of experience creating automated tests and integrating them with build tools and he gave a well structured, interesting, well delivered presentation. I have posted a copy of Chris’s slides and I think the video will be posted on the SF JUG site at some point, but I have also posted my notes from the presentation below…

Selenium Overview

Chris started off with an overview of Selenium – a tool for automating tests for web based applications. He then introduced us to the Selenium IDE – a Firefox add-on that allows you to set up tests by recording clicks on a web page, or by manually entering commands. The tests can then be played back as part of your automated test suite.

Creating Selenium Tests

Chris showed us the process by both executing an existing test he had already setup, and by walking us through the creation of a new test, which loaded a page, waited for text to be present, clicked on a link, and confirmed that text was present. The test was a html file, but he showed how to export it as TestNG and JUnit tests (although both exports resulted in kind of ugly java code!)

Possible hiccups with Selenium

One of the things I thought Chris did well was, in addition to pointing out all the many great things about Selenium, he also pointed out some of the slight issues with Selenium that he has encountered during his time using it, such as

• Difficulties getting the initial Open page to work
• Issues with where the test files get saved
• Making sure you have the tests run slow to start with (to avoid timing/loading issues)
• The Selenium IDE may be difficult to get working with IE (Firefox is fine)

Selenium Components

The main Selenium section then finished up with a quick over of the various Selenium Components:

• Selenium IDE
• Selenese Commands
• Selenium RC (Remote Control)

Chris also had a section on the ‘same origin‘ JavaScript policy that Selenium manages to circumvent by using the Selenium RC Server. He managed to explain the issue in simple terms.

Other functional test alternatives

Chris discussed other functional test alternatives by comparing Canoo to Selenium (Canoo is also an automated web app testing framework).

Chris also mentionted Umangite, Chris Richardson’s open source testing framework that makes Selenium tests easier to write. I have used this before, and agree it is worth checking out…

Using Selenium with Build Tools

He then discussed using Maven with Selenium, including using Cargo (e.g. using the cargo maven2 plugin). Cargo is a set of APIs that assists in

• installing web containers, such as Tomcat, JBoss
• booting and shutting them down
• deploying web apps (.wars, .ears)

Chris finished the Selenium & build tools section with a quick run through of using Selenium with Ant.

Continuous Integration

The final section of the presentation was a talk on Continuous Integration (CI). Chris described CI as:

• A dedicated box (see my follow up question below!) that runs regular full builds (including tests) of your software
• Build triggers when any developer checks into SCM
• Team is notified of any issues

And talked about how Selenium can be used with Hudson – a very cool CI tool from Sun. This leads well into next month’s SF JUG talk!

Q&A

Q: Do you have any info on WebDriver merging with Selenium?
A: No, but sounds interesting!

Q: How closely do test writers work with marketing people?
A: Chris suggested checking out the easyb framework, a behavior driven development framework that allows you to write conditions in a very abstract level, using a DSL that marketers can use and understand. He also suggested looking at the fitnesse framework.

Q: I asked Chris via email after the talk what he meant by needing ‘dedicated’ box/server for Continuous Integration.
A: He clarified that by ‘dedicated’, he just meant that the build box should not be a box that you are doing development on, and that there isn’t anything wrong with having a mix of services on one machine. e.g. having a qa box that has the CI server and maybe hosts the bug tracking system as well…

• System.out.println becomes simply println
• for (int i-0; i<10; i++) becomes for ( i in 0..9 )
• Accessor methods are autogenerated and used

Sure, the poor IDE support is a little annoying, especially the lack luster code completion and debugging capabilities, but I am sure it will improve soon (especially with SpringSource on the case).

But then I started to notice some slowness when using it. So, I performed a simple performance comparison and the results shocked me.
I wrote an identical loop in both Java and Groovy (see the code below) which simply loops a million times.

• The Java version took ~5ms
• The Groovy version took ~500ms

I was shocked! Could Groovy really be a 100 times slower? I had heard rumors about Groovy being a bit slower than Java, but I hadn’t expected it to be this dramatic. Surely this is drastic enough to stop Groovy being used in serious, production quality projects?

I discussed this with a friend who is a Groovy advocate. He made the following points:

1. I was running with an older, slower version of Groovy

This is true. I ran the tests in Eclipse 3.5, with v1 of the Eclipse Groovy plugin, which uses v1.5.7 of the Groovy compiler.
However, when I downloaded the latest version of Groovy (Version: 1.6.3 with JVM: 1.6.0_13) and ran from the command line, it still took the Groovy code ~200 ms. A huge improvement, but still ~40 times slower than Java.

2. It is an artificial, unrealistic test, as these kind of huge loops are not normal in most programs

This is also true. But although artificial, it is still a straight comparison. Also, these kind of loops aren’t so unusual in Project Euler type problems (at least in my crude brute force solutions!).

There are also some more detailed Java/Groovy performance test results here and here.

So, overall, I think the performance is a big issue. But not enough to stop me using it for pet projects. I am even going to keep trying to use it for Project Euler – it will be more motivation to avoid the brute force solutions. It is however, enough to stop me using it in any serious production apps.

For the record, here is the exact code I ran:
Java version

		long max = 1000000;
		long start = Calendar.getInstance().getTimeInMillis();
		for(int i=0;i<max; i++) {}
		long end = Calendar.getInstance().getTimeInMillis();
		long duration = end - start;
		System.out.println(duration);

Groovy version

		long max = 1000000;
		long start = Calendar.getInstance().getTimeInMillis();
		for(int i=0;i<max; i++) {}
		long end = Calendar.getInstance().getTimeInMillis();
		long duration = end - start;
		println(duration);  

It is also worth pointing out that when I changed the Groovy code to use proper Groovy syntax, as in for (i in 1..1000000) is was substantially faster (although still significantly slower than Java), but I have left it as is, for a apples vs apples comparison.

However, there is another option for dealing with recoverable problems, i.e. using return values.

Read full article & Comments

Read full article

Initially, I had my hibernate.cfg.xml file in the following directory

my-app/src/main/java

And when I first tried to run my hibernate unit tests (mvn test), I got this error:

SessionFactory creation failed.org.hibernate.HibernateException: /hibernate.cfg.xml not found

Some checking of the maven docs and some forums revealed the following possible solutions:
1) Copy the hibernate.cfg.xml file to

my-app/target/classes

This works, however I think it is a hack as the target folder is generated rather than being somewhere you should actually manually create files.
2) The next solution I found suggested moving the hibernate.cfg.xml to

my-app/src/main/resources

This works well as the contents of this folder are copied to the base level of the my-app/target/classes folder so it is basically a ‘more correct’ solution than the first.
3) The next and I think best solution was to create a new, duplicate hibernate.cfg.xml inside

my-app/src/test/resources

This allows a different hibernate.cfg.xml file to be used for testing and, for example, facilitates connecting to a different database (such as hsqldb) for testing while continuing to use your regular database (such as MySQL) for the app itself.

A couple of points to note:

1) The hibernate mapping files (i.e. the *.hbm.xml files) should also be in the resources folder (in whatever directory structure you choose) to ensure that these too are accessible by the unit tests.

2) I am not (yet) using Spring with the hibernate components, which would likely have changed the above setup.

Refs/links

http://maven.apache.org/guides/getting-started/index.html#How_do_I_add_resources_to_my_JAR

http://www.mail-archive.com/users@maven.apache.org/msg54720.html

Check it out at http://findbugs.sourceforge.net/

Update: Found recommendations for another tool called JLint, which is supposed to be particularly good for spotting potential deadlocks so perhaps worth using when testing threaded code.