> > 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.
Seems good. This is in the line of what I was thinking. > > > 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 :-) > > 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). This is exactly what I want to highlight. Starting with JBehave, I found that the tools set made available, was pretty much developer centric. First of all, in my case the BAs does not have access to SVN. (Not sure if this is something one could argue is something they should have). From my (as a developer as well as JBehave's) prespective it makes totally sense to have the .scenarios file in SVN. What I would like to see, is a GUI front end to the .scenarios as well, that is synchronized with SVN, that makes them available to the BA without having to deal with scripts to be ran, or similar. I think my reason for bringing attention to this, is that this is what I see as the hardest part to "sell" to the BA when suggesting to go more BDD. What I have seen so far, this is the weakest part of the BDD/JBehave "story". What I see is that BA's most often uses tools like powerpoint, excel and similar in their everyday worklife. Some has background using a commandline interface, but most have not. I'm not sure that "forcing developer centric" tools upon them is really the easiest way to gain acceptance for BDD and tools like JBehave. Then again, this is my first approach to BDD, and I'm happy to learn from all the experience out there. > > > 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. Totally agree on you on this. My intention was never to say that the BA's should never "see" the .scneario files (nor that they are not smart people, those I've met are very, very clever and smart persons). I'm sorry that my reasoning was interpreted this way, it was not what I tried to say. Again, as mentioned above, my conern is more on _how_ the BAs are getting access to the .scenario files. From what you are saying, there is no single way to the goal here, which means that the developers needs to spend some time to get this process in place. > > > 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. I'll take a look at this. Thanks for your tip. > > > 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. They are very useful. Being a newbie to BDD, I'm hoping to learn as much as possible from all the great experience out there, and hopefully avoid as many pitfalls as possible. Cheers, E
