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@.
No Trackbacks
6 Comments
Where do I get it? Google wasn’t helpful.
Get it here: “http://jbehave.codehaus.org/”: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”:http://abbot.sourceforge.net/ – 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.