Hi Ben,
without wanting to go into a detailed comparison (would need to catch up
on what Cukes folks have been doing of late), I would say that JBehave
is more suited for Java-centric development that Cucumber, which is
written in Ruby. While both languages can invoke code written in the
other, there are good reasons to prefer an all-Java solution.
Among them:
- seamless integration into any Java IDE - particularly useful for
debugging
- ability to run scenarios without having access to a dev env (ie CLI,
SCM etc ...) via the Web Runner.
- may be more difficult to introduce a new language in the tech stack
(albeit only for integration testing purposes) in a corporate environment.
Cucumber offered up to now better CLI support, in particular via it's
nice terminal colour coding, but I think the gap is narrowed by the HTML
reporting in JBehave.
In the end, which BDD framework you end up using is a decision that
depends many factors, not least the tech know-how within your team.
Recommendation is to choose the tools that best fits the requirements
you have.
Cheers
Ben Sullivan wrote:
Great - thanks Mauro.
Could I ask in your opinion, feature wise, how do you think JBehave
stacks up against Cucumber? I am trying to figure out which way to go
at the moment. They are pretty similar from what I've seen so far.
Beyond the feature debate, I am leaning towards JBehave at the moment.
I come from a Java/Groovy background. I am a strong advocate of
tracking technical debt (be it test or prod code) in order to make
informed decisions around the highest value refactorings to target. I'm
not (yet) convinced the code analysis tools (e.g. CheckStyle, Clover,
FindBugs, Sonar) or Jetbrains IDE refactoring support for dynamically
typed languages are as good as what is currently available for Java.
I'm sure this will change....
Interested to know your thoughts...
Thanks
Ben
On 01/01/2010, at 11:49 PM, Mauro Talevi wrote:
Hi Ben,
JBehave already supports the specification of a story/feature
narrative as you describe below. I've updated an example story to
show it:
https://svn.codehaus.org/jbehave/trunk/core/examples/trader/src/main/java/org/jbehave/examples/trader/scenarios/trader_sells_all_stocks.scenario
The current impl captures everything before the first Scenario as
unstructured text (hence the name Blurb in the domain module). Hence
not an issue in a plain text report (newlines are maintained) but
becomes less readable in, say, HTML.
What perhaps would be interesting is to add an optional Narrative
element with keywords, so as to be able to distinguish between the
various elements of the narrative ("In order to", "As a", "I want to").
I've created an issue to track this:
http://jira.codehaus.org/browse/JBEHAVE-230
Cheers
Ben Sullivan wrote:
Hi
In Cucumber you can do this:
Feature: Some terse yet descriptive text of what is desired
In order to realize a named business value
As an explicit system actor
I want to gain some beneficial outcome which furthers the goal
Scenario: Some determinable business situation
Given some precondition
And some other precondition
When some action by the actor
And some other action
And yet another action
Then some testable outcome is achieved
And something else we can check happens too
Scenario: A different situation
...
I noticed the JBehave EBNF caters for stories simply as a one or more
scenarios. Are there any plans to allow more details to be fleshed
out around the Story in JBehave like you can do in Cucumber?
Even if it were just:
Story := "Story:"? Description? Narrative? Scenario+ ;
Narrative := (Word Space?)* ;
We'd have a placeholder to give some story/feature context to our
acceptance scenarios which I think my customers would really like.
Cheers
Ben
PS - nice work on the reporting stuff in 2.4 release!
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
