magpiebrain

Sam Newman's site, a Consultant at ThoughtWorks

At last Wednesday’s “Geek Night in London”:http://geeknight.thoughtworks.com/index.php/GeekNightLondon, we had a presentation of three related software development projects. I’ll give a brief write-up of each of them, starting with “JBehave(Codehaus – JBehave)”:http://jbehave.codehaus.org/.

JBehave has been written as a replacement for JUnit, with a view for better suiting Test/Specification/Behaviour Driven Development (someone please write a book and rename this!). The first thing apparent from looking at JBehave, is the change in language:



public class TimerSpec {
    public void shouldMeasureAPeriodOfTime() throws Exception {
        // setup
        Timer timer = new Timer();
        timer.start();

        // execute
        // TODO make this not time-dependent - could possibly fail
        Thread.sleep(10);
        timer.stop();

        // verify
        Verify.that(timer.elapsedTimeMillis() > 0);
    }
}



The replacement of the words @test@ and @assert@ for @should@ and @verify@ is reinforcing the fact that this tool is used to specify expected behaviour of your code, rather than testing your code (on a personal note, @should@ sounds a little limp – @will@ or @shall@ would be better choices). Beyond the simple language changes, JBehave is actually quite a different beast when compared to JUnit. As you might of noticed from the above test, there is no longer any reason to extend from some arbitrary class – you simply provide a class with methods beginning with the word @should@. Additionally, the whole structure is event-based, so developers can easily extend its behaviour by attaching custom event listeners – listeners can be added to detect the start and end of each specification, and the start and end of each individual @should@ method. A simple example use of listeners would be creating custom loggers, but more advanced uses could include the ability to automatically generate specification documentation or provide close IDE integration.

Right now JBehave seems to do everything JUnit can do. What is required next is tool support – the only thing stopping me from using it is the lack of an IDEA plugin, and without it I won’t be able to get my @Ctrl-Alt-F10@ green-bar mojo working… The developers can be contacted on the JBehave mailing lists @dev {at} jbehave {dot} codehaus {dot} org@.

Advertisements

6 Responses to “JBehave”

  1. Kevin

    Ok, I am game. I am wondering how I can do something like what jfcUnit provides, to automate testing of my Swing/SWT GUI? Anything in the works? Perhaps jfcUnit merely needs to provide a new class that extends JBehave somehow?

    Reply
  2. chris

    hi, i would just like to ask if i could use Jbehave as a framework for testing SWT applications? It seems to me that Junit can’t be extended for this (except of course with Abbot)? If not, do you have any suggestions on what frameork to use for testing SWT apps? thanks.

    Reply
  3. Sam Newman

    I can’t see why not. JBehave can integrate with JUnit so you can take advantage of all the tools built on top of JUnit (such as abbot).

    For functional testing like this you may be better of looking at something like FIT with the appropriate driver – for example using a nice FIT table to describe your test, which in turn drives a lower-level abbot layer to do the button pushing.

    Reply

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Basic HTML is allowed. Your email address will not be published.

Subscribe to this comment feed via RSS

%d bloggers like this: