> > As a practical point, you can present a subversion repository as a Windows > "Internet Share", using Apache and mod_dav. This appears as just a regular > share to your users so they can map it as their G: drive or something. Each > time they save a document on the share, it creates a new version in the > repository. > > That way they don't even need to know they are using version control unless > they want to, and they can get back to any previous version of their > scenarios. > > Another possibility is to keep all the scenario text in a flat file-based > wiki (like moin moin) and keep the wiki content itself in the same > repository as the code, so you can see the scenarios evolving with the > codebase. Liz is doing this on her current project (although it's .NET so > she isn't driving jbehave scenarios from the wiki text). >
I think one of these is what I am looking for. Thanks for the tips. > > > Hmm - perhaps that would make a nice plugin - reading the scenario from a > URL rather than a text file? > That might be convenient. > > > Alternatively, having a script that checks out or exports scenarios into a >> common filesystem area is a way of exposing them to people that don't have >> access to source control. But is a simple sysadmin task, and one that can >> hardly be generalized. >> >> Else, BAs could write their scenarios as story cards using whatever >> system you're using to track them. Even something as simple as a wiki would >> do. Again, it's up to your team to decide what works best for your >> development environment. JBehave keeps the requirements very simple. > > > Perhaps we should start collecting the different use cases for how BAs, > testers and other non-developers might want to interact with the scenario > text? > I'm happy to share my experiences when I get some. > > > >> 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. >> > > The simple text file format has been chosen because it is universally >> usable - any editing tool would be able to open it. > > > I agree. You can open and edit a text file in Word if you want to (and you > might want to because of things like the spelling checker, and the simple > fact that it's a familiar environment). > Agreed, I have nothing against the text file itself. > > > >> I have been thinking about supporting imports from other binary formats, >> into a textual format - which is the only one suited for source control >> (created issue to track it http://jira.codehaus.org/browse/JBEHAVE-149). > > > I would go the other way, and edit plain text or html files using Word, > which can happily save as either. > I agree to Mauro, collecting the scenarios using a spreadsheet might be handy. Excel makes it easy to organize and re-prioritize. > Exactly. I think it would be a useful exercise to describe the different > use cases you can envisage. > At the time being, I'm still completely new to BDD, and I'm trying to learn from all the experiences that are out there. I'm happy to share my thoughts as I get some experiences though. All in all I find BDD appealing, but at the same time I think that the tools used to make BDD happen should not introduce too much technicality into the project (which I is afraid will drive attention away from the goal; making good software). I appreciate all you inputs and you guys taking the time to follow up on my first steps toward BDD. :) Cheers, Egil
