Referring to my previous blog entry, the public Maven repository now carries the 0.8 version of JspTest.

You can take it into use by adding the following to your pom.xml:

    <dependency>
      <groupId>net.sf.jsptest</groupId>
      <artifactId>jsptest</artifactId>
      <version>0.8</version>
    </dependency>

I just did something that's been on my to-do list for a looong time. I hacked on JspTest a bit to tick off some age old todo's:

1. JspTest now has basic support for mocking tag libraries
2. I got rid of the kind of nasty dependencies to a gazillion .jar files (by getting rid of HttpUnit)
3. I converted the Ant-based build script into Maven
4. I put together a public release

There's a lot to do, still, such as documentation, JSP 2.0 support, better facilities for mocking stuff, better support for HTML-based assertions, etc. For example, you'll have to figure out from the (hopefully intuitive) API how to use the damn thing and you'll have to implement pretty much all assertions for the rendered content yourself. It's getting better all the time, though!

One of the big things I did that wasn't on the above list is the public release. You no longer need to check out from Subversion but rather just download a zip file. The only release available through Sourceforge is 0.6, however, and the above improvements were made to 0.7 for which you'll have to wait a bit longer. Those improvements did not change the relevant APIs, though, so there's no reason not to get a head start with 0.6 while you're waiting for 0.7.

Having a public release is an improvement in itself but giving JspTest a try is also getting easier now that the project is using Maven. That is, once the little squirrels behind the public Maven repositories get the POMs and JARs uploaded, you can simply add JspTest as a dependency into your own pom.xml and start writing tests!

Oh, and voting for the ticket would help in getting the squirrels moving!

Recently a lot of people have been asking how to test for expected exceptions. I kind of cover this in my book but since not everyone will buy it and considering that my old blog entry about creating suites with JUnit 4 is one of the most popular ones according to my logs, I thought I should write a quick blog post about it.

So here it is:

import static org.junit.Assert.fail;
import org.junit.Test;

public class TestExpectedExceptions {

    @Test
    public void testForExpectedExceptionWithTryCatch()
            throws Exception {
        try {
            Integer.parseInt("This should blow up...");

            // Uh-oh! No exception was thrown so we 
            // better make this test fail!
            fail("parseInt() should've thrown an exception!");
        } catch (NumberFormatException expected) {
            // this is exactly what we were expecting so 
            // let's just ignore it and let the test pass
        }
    }

    @Test(expected = NumberFormatException.class)
    public void testForExpectedExceptionWithAnnotation()
            throws Exception {
        Integer.parseInt("This should blow up...");
    }
}

In simple terms, here's what the above code snippet illustrates:

Classic Try-Catch Structure

The first test uses a JUnit 3 and 4 compatible try-catch structure for making sure that, if the code under test does not throw an exception, we'll fail the test case by invoking Assert#fail(). We leave the catch-block empty here but we could also make further asserts about what information we expect the thrown exception to contain. For example, we might assert that the exception's getMessage() method returns a description that contains some specific keyword.

Compact Annotation

The second test uses a JUnit 4-only feature that builds on the concept of annotations introduced into the language by the release of Java 5. In this less verbose example, we simply interact with the code under test in a way that we expect to cause an exception to be thrown. Normally, a test method throwing an exception would make JUnit flag that test as a failed one but since we have defined the expected parameter to our @Test annotation, JUnit instead fails if the method doesn't throw an exception (and, specifically, that type of an exception).

Which one should I use?

So these are the two options. If you're using JUnit 3, then your only option is the first one. If you're using JUnit 4, then you can choose between the two and decide, case by case, whether you like the compact form more. The compact form does not allow assertions against the thrown exception, though, beyond its type so you'll probably end up using both anyway.

I hope this was helpful.

Another small moment of joy...

I recently found the first public review of my book from Ed Gibbs. Thanks for the kind words, Ed!

I've also received some encouraging feedback based on the first 4 chapters through the book's author forum.

This is exciting! Oh, and those of you who've subscribed to the early access program through Manning's website, you should be getting the next couple of chapters in a week or so.

Ok. That's all for now. I still need to prepare a bit for a Scrum training I'm giving tomorrow so I better get offline for the rest of the day...

Morpheus: There is a difference between knowing the path and walking the path.

I was just browsing some of the forums I frequent at JavaRanch and stumbled onto a post by one M. Easter. What caught my eye about this particular post wasn't as much its content as it was the poster's signature that said, "M. Easter, software composer".

Somehow I like that title quite a lot as the metaphor to composing a song works so well on some level.

Anyway. While I was fascinated by Mr. Easter's signature, I also noticed that in his post he had included a link to a blog entry about becoming a TDD believer. Check it out!

It's a shame people don't report their experiences (good or bad) more often.

Oh, I forgot to mention that there's a discussion forum for the book where you can ask questions about the book and give feedback on the chapters as they are being released.

I see that Oskari already went and broke in the forum with a congratulatory note - thanks!