JBehave
At last Wednesday’s Geek Night in London, we had a presentation of three related software development projects. I’ll give a brief write-up of each of them, starting with JBehave.
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.
This entry was posted on Tuesday, July 27th, 2004 at 3:16 pm and is filed under Java. You can follow any responses to this entry through the RSS 2.0 feed. You can skip to the end and leave a response. Pinging is currently not allowed.
6 Responses to “JBehave”
Where do I get it? Google wasn’t helpful.
Get it here: http://jbehave.codehaus.org/
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?
There is a relatively good automated testing tool in the shape of Abbot – I don’t know if it can be used with JBehave though, although I believe JBehave tests can be run inside JUnit, so its a possibility.
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.
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.
Have your say
Fields in bold are required. Email addresses are never published or distributed.
Some HTML code is allowed:
URIs must be fully qualified (eg: http://www.domainname.com) and all tags must be properly closed.
Line breaks and paragraphs are automatically converted.
Please keep comments relevant. Off-topic, offensive or inappropriate comments may be edited or removed.