Hi Mauro,
Thanks, that was about the answer I had hoped for. Yes, Ive used the archetypes, Ive tried to reverse-engineer the questions I had and integrate what I wanted into the then-existing (pretty complex) Maven+(Jenkins|Eclipse) build process based on that insight. Making the archetypes work was indeed reasonably OK, finding out how to think about JBehave from the right angle and then transferring that into the real project was the hard part. By the way, when researching magen, it seemed to me that file locations and directory hierarchies are a recurring topic when using maven, even independent of JBehave. What I was mostly missing was the thinking behind all the things that are touched upon in todays tutorials and archetypes. The stuff that is so obvious to the JBehave pro that you cant even think of it explicitly, and therefore it isnt written down anywhere. As you, Mauro, put it: Sometimes though it's not so easy to judge this steepness when one is too close to the development. I know that phenomenon. Ill give the getting started topic a shot over the next days. As a first idea, Im thinking of: - Prerequisites: maven. Maybe there is a good maven tutorial somewhere we can link to, maybe there is a simple (!) way to experiment with JBehave without maven. (What is the simplest set-up with JUnitStory in Eclipse?) - Basic JBehave concepts o Embedder, Embedding, basic execution: How does JBehave get executed in the first place? (execution as JUnit and execution in maven) o What are the basic phases within JBehave? (I guess: Configuration, Story loading, matching against step implementations, reporting) How do they relate by default to maven phases? o Configuration and loading stories (StoryLoader) o Step implementations o Reporting basics o and how all this relates to each other. - A minimal step-by-step-documented maven-set-up (what file goes where and why, what is the thinking process for the person doing the set-up during configuration) This is my current best candidate for Getting Started. Its pretty close to whats there, Id just like to add some details (e.g. maven and directory conventions) and some overview (how do things relate to each other). While writing the above, I started to feel that a lot of this is about lifecycles: Outside-in 1. There is a lifecycle of the project as a whole. JBehave may be there from the very start, or it may come in later. 2. There is a lifecycle of the JBehave aspect of the project, i.e. configuration and story loading 3. There are lifecycles for every story. 4. There are lifecycles for every build run. This has a common part (basic phases above) and variation depending on environment: in an IDE (Junit-integration), in a local build (Console output) or on a CI server (fancy reporting) Explaining things inside-out (starting from JUnit in Eclipse), then adding complexity (local build etc.) and climbing the lifecycle ladder from 4->1 might make the whole thing nicely digestible. Im not yet sure what to make out of that, Id just like to bounce these thoughts off the experts early. What do you think? Is my understanding of how JBehave works technically correct (even if intensely simplified) so far? Could these approaches be helpful to lower the barrier of entry even more? Last but not least, Mauro, could you please get me a JIRA user so I can raise the JIRA issue according to http://jbehave.org/reference/stable/how-to-contribute.html Thanks, all. Have a great weekend. Best regards, best wishes, Josef From: Mauro Talevi [mailto:[email protected]] Sent: Freitag, 7. März 2014 09:17 To: [email protected] Subject: Re: [jbehave-user] JBehave learning curve Hi Josef, I think it's a fair comment to say that JBehave is development-centric (not necessarily developer-centric though) as its main focus has always been the ability to support CI. As such it does require some knowledge in the team with respect to build and SCM technologies and the likes. It could be qualified as a toolkit - which needs to be customised and adapted to the project needs. Once set up it can be used by less technical members of the team. As for your points below, have you ever tried using archetypes: http://jbehave.org/reference/stable/archetypes.html They are meant precisely for the purpose of getting people started with a simple but working project. There is a jbehave-spring-archetype which sets up the autowiring of steps classes using Spring. That said, we always strive to improve the documentation and make the learning curve less steep. Sometimes though it's not so easy to judge this steepness when one is too close to the development. Help from someone like you who's not a full-time developer would be very welcome. If you have time to provide a doc page as a patch that would detail how you'd approach a "getting started" page, it'd be great. http://jbehave.org/reference/stable/how-to-contribute.html Thanks for your feedback. On 06/03/2014 14:36, Josef Dietl wrote: Hi Janusz, Thanks for taking up this topic. I was having similar problems to get started, and for organizational reasons, I couldnt approach the group. I dont mean to offend anybody. Everybody here is incredibly helpful, and the software is really great. But the learning curve is wild. Given the deep questions I saw here while lurking, I wasnt exactly inspired to step up, despite all the helpful attitude of Mauro and everybody. A bit about myself: Im not a full-time developer, Im a project manager with a passion for continuous improvement of our development practices. Im good enough to occasionally find something in a code review, to make a prototype or an automated test, but my focus is on providing the optimal environment for the development team so that they can maximize their productivity. So in order to get them to look at JBehave and [T|AT|B]DD, I had to learn Maven and set up JBehave on my own in a branch of the project to demonstrate the value-add. To cut a long story short, once I was through, adding stories and tests on top of the existing set-up was cool and convincing, but the path there could have been smoother. When I was working for the W3C, we had a saying: make the simple things simple and the hard things possible. JBehave doesnt exactly work like that, but once I had reached the hard things, I also found traction in the documentation and the sample projects. I dont have the role to suggest anything here, but I did ask myself repeatedly whether it wouldnt be possible to be more explicit about the first steps. Back then, Ive tried my best here -> http://digitaler-heimwerker.de/2012/10/26/howto-maven-spring-und-jbehave/ (unfortunately German). If a check with Google Translate suggests that this is basically useful, Id translate and tweak this and its sibling post (below) as needed and contribute it. Re-reading the post, I find that I struggled most on these topics: 1. What is the simplest possible working configuration of JBehave? (theres a description on the site, but no full example what are the main classes, what is their relationship to each other? What do I need to import from where? Reverse-engineering the thinking steps from the example projects just didnt work for me.) 2. Depending on JBehave configuration and Maven configuration: Where do I have to put this file, the stories and the step implementations? 3. And then, specifically for my almost-simplest-possible set-up: how does all this relate with Spring. In hindsight, the biggest problem was #2: Which file goes where (or, more precisely, as everything is configurable: which configuration determines what goes where, and what are the defaults?) For a slightly more advanced topic, theres even a post in English: http://digitaler-heimwerker.de/2013/03/04/mocking-file-access-for-testing-wi th-jbehave-and-easymock/ I hope this helps. JBehave is really great, and I hope this message is advancing its progress. Thank you all for your great work! Best wishes, Josef From: Janusz Kowalczyk [mailto:[email protected]] Sent: Donnerstag, 6. März 2014 12:58 To: [email protected] Subject: [jbehave-user] Why JBehave repo examples and website are the worst example of work ever created by the any of the open source communitties? It's truly remarkable that I haven't gave up yet in my attempts to use JBehave many after days wasted on trying to figure out how to run examples give on the jbehave.org or the ones available in the project's repo. Does any of the project members heard of Developer Experience? Are there any chances that this will change in near future or this project will keep to scare off more people? Cheers J
