Hi Egil,
Egil Østhus wrote:
I'm new to BDD and JBehave, but really likes the idea it brings to the
table. I would love to really test this out in a "real project". A
couple of questions I have, that I have not been able to find the
answers to after some searing on goole as well as on this list. (Beware
with me if I missed a mail entry on any of my questions).
happy to answer any questions you may have.
1) Is there a way to automatic generate both the Java scenario files as
well as the Java Steps files? I've seen some similar comments on the
list around a year ago (?), and it didn't seem supported then. Is this
still the case?
You're probably thinking of a feature that was in JBehave 1.x, in which
Java scenarios were converted in textual representations.
In JBehave 2.x we've turned the paradigm on its head: you start from a
textual (or otherwise formatted) scenario, i.e. not a Java code file,
representing the behaviour of the system and you then match the steps in
it with annotated Java methods in the Steps class.
At the moment, the process of writing the matching Java steps is manual,
although I've started to think about a way of automating the generation
from the scenario. You gave me the kick I needed to write it down:
http://jira.codehaus.org/browse/JBEHAVE-148
Feel free to comment and add suggestions of how you would like it
working, if any different.
2) Does anyone have any experience on how to best drive a BDD project
using JBehave? To me JBehave seems developer driven, meaning that the
.scenario files would typically live in SVN (or similar) somewhere well
hidden down in a directory (e.g. src\scenario\java\com\acme\feature1 for
a mvn project). I see myself having a hard time to convinse my business
analyst to start using svn and look around for the .scenarios file well
hidden in the source directory. Is there any "business analyst" front
end to the scenario files that could be used? I guess that some will
argue that the business analyst should not see the .scenarios file at
all. Instead of using files, use index card and a cardboard. My
challenge is that if I'm going for BDD is that the dev team, the dev
lead and the business analysts are distributed, and index card doesn't
really work that well on web conferences. I appreciate any thoughts and
experiences you guys have on this.
Not sure if this is the best list to discuss this, but it is worth a shot :)
I would argue this is the most appropriate list - actually :-)
IMO BDD is not "developer driven" in the sense that TDD is - where in
the latter tests are written by developers for developers - but it is
development-aware because its primary focus is to allow *automation* of
scenario running. You could then say it's "development driven" where
you include *all* members in the development team (i.e. developers,
testers, QAs, BAs, etc ...) - as is customary in an agile environment.
JBehave's textual scenarios are meant to speak the language of the
business and be agnostic (as much as is reasonable) of the technological
implementation issues. They should express the business domain and the
criteria to assess whether a story is "done".
The fact that the textual scenarios live in SVN is more a practicality
than anything else, making it easier to map textual and Java scenarios.
One could easily find ways of mapping the two even were these to live in
different places. But that's not the issue, really. It's important
that ultimately the scenarios do end up in SVN because they represent
the "contract" for the features being implemented (rather than hidden
away in some equally unreachable CMS or document). But the
intermediate steps of publishing the textual scenario somewhere on the
filesystem and allowing product owners and BAs to access them is a very
simple task indeed. Then they can be modified and any changes
committed. For example you can have a simple scripts that does a
checkout or export of the scenarios package only (and its sub-packages).
But I disagree with your suggestion that BAs should not see the textual
scenario files. On the contrary, they *should* be writing them in the
first place. BAs are smart people and they are part of a development
team (using the broader agile definition as above). There is no real
reason why they cannot write simple textual files, if they can use more
complex editing proprietary tools. And if they can write story cards,
they can write scenarios. But this is a matter for your team to
self-organise and decide what works for you. If you are happy for the
BAs to write story cards and the developers to transfer them to scenario
files, then be it. I do envisage it not being too easy to specify the
input and output data of the scenarios on story cards, if the system
under test is very data-centric. Typically, textual scenarios will also
have associated data files that are read in the running of the scenarios.
BTW, if you are in a distributed environment and are using Jira as your
issue tracking tool - you may want to have a look at GreenHopper plugin
which provides agile story and task board views of the Jira issues.
It's a commercial plugin, but at a reasonable (per-server) price, at
least compared to other agile management tools that employ a per-seat
pricing scheme.
3) Any experiences on what CI servers that works "the best" with JBehave?
Any CI server will do - as long as you use a CLI to JBehave, either via
Ant tasks or Maven plugins.
Hope these comments are useful. Do feel free to give us feedback and
continue firing away with further comments or questions.
And if you feel that there are any features that you'd like to see
implemented, we'll be more than happy to consider any. The best way to
convince us is to provide a realistic use case or example.
Cheers
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
