Hamcrest

Hamcrest is a framework for writing matcher objects. Matchers have a variety of uses, but are particularly useful when writing unit tests. Instead of using JUnit’s assertEquals methods, we use Hamcrest’s assertThat construct with one (or more) of the many Matchers available. For example

    assertTrue(a.equalTo(b));

becomes

    assertThat(a, equalTo(b));

A small change in this example, but Hamcrest’s benefits are many, enabling you to write much more flexible tests that are easier to read and have more meaningful failure messages.
Read more

Tags: Hamcrest, JUnit, Testing

Selenium talk at SF JUG

I attended another great San Francisco JUG meeting tonight, this time on How to use Selenium with Maven/Ant to automate testing of web apps.

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…
Read more

Tags: JUG, q, selenium, sfjug, Testing, unittesting

Running Hibernate unit tests with Maven

I recently converted a project I have been working on to use Maven. After setting up all the dependencies in the pom, I got everything compiling fine but ran into problems getting the unit tests to pick up the hibernate config (hibernate.cfg.xml) and hibernate mapping (*.hbm.xml) files. With hindsight, it is straightforward, but it took me a while to figure it out so I thought I’d post the solution here.

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

Tags: Hibernate, Maven, Testing

Silicon Valley Code Camp Notes

I am at the Silicon Valley Code Camp at the moment.

I will try to post some notes on the various talks I attend below…

Day 1:

• Session 1: JavaScript
• Session 2: Easing into Agile
• Session 3: Building Better Tests in Java
• Session 4: What is Python?

Day 2:

• Session 1: Basics of Threading
• Session 2: Introduction to Grails

Tags: agile, codecamp, Java, JavaScript, python, Testing, threading

FindBugs

Came across this really neat tool that can actually find bugs in your code. It uses ‘static analysis’ to find instances of bug patterns – code instances that are likely to be errors. I was pretty skeptical until I ran it on some code and was impressed by the results. It found loads of possible problems. I’ll definitely be using it again.

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.

Tags: Testing